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Abstract 


Specification  of  the  timing  properties  of  real-time  systems  is  a 
fundamental  part  of  their  requirements.  Analyzing  the  timing  properties  of 
the  system’s  design  and  implementation  is  an  important  issue  for  the  system 
developer.  Timing  analysis  is  necessary  to  determine  the  validity  of  a  design 
or  implementation  in  respect  to  the  real-time  specification. 

Using  timing  schema  and  PERT  networks,  Ada  program  timing  behavior 
can  be  analyzed.  The  use  of  PERT  networks  is  simple  but  restricted  to  single 
processor  systems.  Replacing  the  PERT  networks  with  a  communicating 
real-time  state  machines  model  allows  the  analysis  of  Ada  programs  on 
multi-processor  systems. 

The  technique  is  developed  with  examples  and  applied  to  a  Macintosh  Ilsi 
programming  environment.  A  foundation  is  laid  for  measuring  how  good  a 
timing  analysis  prediction  fits  the  implementation. 
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Chapter  I 


Introduction 


Motivation 

A  gap  often  exists  between  stating  the  requirements  for  a  real-time 
system  and  determining  if  a  design  matches  those  requirements.  Timing 
requirements  suffer  much  from  lack  of  adequate  attention  during  the  design 
process  since  techniques  to  analyze  and  abstract  timing  characteristics  are 
difficult  to  find  or  do  not  trace  forward  to  the  implementation.  Since  the 
timing  characteristics  are  among  the  most  critical  in  real-time  systems,  the 
ability  to  track  these  requirements  throughout  the  development  life-cycle  is 
crucial. 

The  simplest  development  life-cycle  model  is  the  waterfall  model.  In  this 
model,  each  activity  —  specification,  design,  implementation,  and  test  — 
occurs  sequentially  after  the  completion  of  the  preceding  phase.  In  practice, 
the  waterfall  model  creates  artificial  bottlenecks  and  places  unrealistic 
constraints  on  the  project.  More  practical  developments,  however,  still 
conduct  the  same  four  basic  activities  [1],  [2].  In  them,  however,  the 
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activities  may  occur  in  different  order  and  repetitiously.  Furthermore, 
different  pieces  of  the  project  may  exist  in  different  activity  phases. 

The  model  for  software  maintenance  is  quite  similar.  The  fielded  system 
has  completed  all  of  the  development  stages.  New  parts  and  modified  parts 
may  exist  in  various  stages  of  completion,  however.  These  additions  and 
modifications  are  certainly  part  of  the  system  and  cannot  be  developed 
completely  independent  from  the  fielded  system.  The  key  difference  between 
software  development  and  maintenance  is  that  system  design  and 
implementation  decisions  may  not  be  available  to  the  maintainers.  While 
doing  the  same  type  of  thing,  maintainers  often  have  less  information  outside 
that  embedded  in  the  system. 

For  an  analysis  technique  to  be  applicable  to  the  entire  project,  then,  it 
must  be  consistent  across  development  activities.  The  technique  must  be 
compatible  with  analyzing  the  system’s  parts  existing  simultaneously  in 
different  stages  of  development.  This  requires  the  technique  to  apply  during 
design  as  well  as  during  and  after  implementation.  The  result?  must 
combine  into  project-wide  results,  and  these  results  must  relate  to  the 
requirements  specified  for  the  system. 

Typically,  real-time  systems  have  finite  worst-case  response  time  and 
workload  requirements  for  specified  scenarius.  Therefore,  a  system  timing 
analysis  tool  must  generate  predicted  response  time  and  workload  measures 
for  the  system  through  the  various  activities  of  the  development  life-cycle. 
Only  with  this  type  of  support  can  syst  em  developers  track  and  focus  on 
timing  requirements  during  system  development  and  maintenance. 
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Objectives 

This  thesis  describes  a  technique  for  analyzing  execution  times  of  Ada 
programs.  The  primary  objective  for  development  of  the  analysis  technique  is 
that  it  can  apply  consistently  throughout  the  development  life  cycle  and 
answer  questions  about  response  times  and  workload  scenarios.  Pyster 
points  out  that  the  “hardest  parts  of  developing  software  are  specifying  and 
validating  requirements  and  design”  [3].  The  primary  objective  of  this  thesis 
focuses  on  validating  the  timing  properties  of  the  design  as  well  as  the 
implementation.  Secondary  objectives  include: 

•  Applicability  of  the  technique  to  different  development  and  target 
environments  with  parametric  differences  only, 

•  Limited  restrictions  on  design  methodology  or  implementation 
style,  and 

•  Few,  if  any,  restrictions  on  applicability  to  legitimate  Ada 
programs. 

The  technique  is  based  on  source  code  timing  schema  [4-6].  The  results  of 
applying  the  schema  is  used  to  construct  a  dependency  graph  of  events 
connected  by  code  segments  where  the  code  segments  are  represented  by 
their  execution  times.  This  graph  can  be  manipulated  to  determine  the 
worst-case  path  between  two  events.  The  resulting  length  of  the  path  is  the 
response  time.  Simultaneous  solution  for  a  scenario  of  events  can  determine 
the  worst-case  processor  utilization  necessary  in  a  specified  period  of  time, 
thus  determining  workload. 
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Organization 

The  thesis  is  organized  as  follows.  Chapters  II  through  IV  develop  the 
schema-based  execution  time  analysis  algorithm  and  concurrency  extensions. 
Chapter  V  presents  and  summarizes  experimental  results. 

Chapter  II  develops  the  background  of  execution  time  prediction  and 
scheduling  analysis.  Existing  prediction  techniques  are  evaluated  with  the 
criteria  described  in  the  objective.  Scheduling  analysis  relies  on  a  priori 
knowledge  of  task  time  behavior.  The  tasks  used  in  the  scheduling  literature 
are  not  necessarily  the  same  as  Ada  tasks.  Thus,  a  context  is  developed  that 
connects  traditional  scheduling  analysis  and  Ada  timing  analysis.  This 
background  sets  the  stage  for  development  of  the  analysis  technique. 

The  execution  time  prediction  method  develops  in  Chapter  III.  Timing 
schema  are  defined  for  a  DIANA  [7]  representation  of  Ada  programs.  The 
schema  is  defined  in  terms  of  primitives  that  partition  language  primitive 
constructs  (declarations,  statements  and  expressions)  into  shared  and 
branch-distinct  portions.  Furthermore,  the  schema  defines  where  context 
switches  may  occur;  these  points  are  defined  as  events.  Compiler  analysis 
generates  execution  time  bounds  for  each  primitive.  These  steps  provide  the 
data  for  an  algorithm  to  transform  DIANA  trees  into  the  analysis  graph. 

This  graph  has  events  for  nodes  and  code  sequences  weighted  by  their 
execution  time  bounds  for  edges. 

Chapter  IV  further  develops  the  concurrency  issues  involved.  It  defines 
the  Ada  concurrency  model.  Some  limitations  on  real-time  programs 
naturally  fall  out  of  the  application  of  the  timing  analysis  technique  to  Ada. 
The  next  step  is  to  manipulate  the  analysis  graph  to  generate  response  time 
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and  workload  values.  Two  techniques  are  described.  One  uses 
Communicating  Real-Time  State  Machines  (CRSM)  [8].  The  other  uses 
PERT  analysis  techniques. 

Experiments  are  designed  to  show  that  the  calculated  times  do  indeed 
bound  execution  times.  Furthermore,  simple  experiments  are  hand  analyzed 
for  worst-case  time  and  compared  to  the  predicted  time.  Finally,  the 
predicted,  actual  and  hand-analyzed  times  are  compared  to  provide  a 
qualitative  measure  of  the  technique. 


Chapter  II 


Execution  Time  Prediction  and  Scheduling 


Introduction 

Execution  time  prediction  and  scheduling  analysis  are  relatively  old 
problems.  Yet,  they  are  far  from  resolved  problems.  The  standard 
techniques  for  determining  execution  time  are  primitive.  This  information, 
though,  is  critical  to  performing  scheduling  analysis.  Only  when  the 
execution  time  of  a  given  task  is  known,  then  scheduling  analysis  may  be  able 
to  determine  whether  all  deadlines  can  be  satisfied.  This  chapter  compares 
existing  time  prediction  techniques  to  the  criteria  of  life-cycle  applicability, 
portability,  and  language  limitations.  It  then  discusses  how  the  idea  of  a  task 
in  scheduling  analysis  relates  to  system  design  and  implementation. 

Tradition? the  execution  time  of  a  program  is  measured  using 
instruction  analysis  of  the  underlying  object  code  or  through  testing  the 
actual  execution  time  of  the  implementation.  More  advanced  techniques  are 
developed  in  [4,  9-14].  These  are  not  used  in  practice,  however,  for  one  reason 
or  another.  By  comparing  these  methods  to  some  criteria  defining  the  needs 
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of  real-time  Ada  program  development,  motivation  develops  for  a  technique 
derived  from  Shaw’s  timing  schema  [4]. 

In  scheduling  analysis  tasks  (italicized  for  distinction)  are  commonly 
defined  as  a  tuple  of  an  arrival  time,  a  period  or  deadline,  and  a  maximum 
execution  time.  This  is  an  abstract  notion  that  relates  well  to  the  context  of 
many  real-time  systems  —  an  event  occurs,  a  task  is  generated  to  react  to  it 
and  must  complete  prior  to  a  deadline;  or,  an  activity  must  occur  periodically 
and  complete  prior  to  the  end  of  the  period.  This  notion  of  a  task  is  very 
different  from  the  Ada  notion  of  a  task.  An  Ada  task  is  a  program  construct 
which  exhibits  concurrency.  These  distinct  ideas  of  tasks  are  resolved  by 
relating  a  task  to  Ada  programming  constructs. 

Traditional  Execution  TTime  Prediction  Methods 

Two  sections  in  Knuth  [15]  discuss  “Analysis  of  an  Algorithm”  and  “O- 
Notation.”  While  asymptotic  analysis  is  useful  in  making  wide  distinctions  in 
efficiency,  it  does  not  relate  directly  to  time.  Deadlines  are  stated  in 
microseconds  or  milliseconds,  not  in  O-Notation.  Two  practical  methods  are 
widely  used.  Knuth  also  discusses  the  first  of  these,  the  hand  analysis  of 
machine  object  code.  He  combines  this  with  asymptotic  analysis  to  generate 
execution  time  predictions.  In  general,  common  sense  and  logic  are  used  to 
derive  meaningful  information  from  the  object  code.  The  other  widely-used 
method  is  benchmarking  or  test  case  monitoring. 

The  most  obvious  drawback  of  these  techniques  to  life-cycle  analysis  of 
execution  time  is  that  they  require  object  code  exist  before  operating.  Thus, 
they  are  of  limited  use  during  implementation  and  only  fully  useful  after  its 
completion.  Hand  analysis  is  also  prone  to  be  highly  complex.  Knuth’s 
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example  [15,  pp.  164  - 169]  takes  an  83  line  assembly  program  and  reduces  it 
to  a  linear  equation  with  six  independent  variables.  To  accomplish  this 
required  an  application  of  KirchofFs  law  to  an  earlier  set  of  15  variables  and 
significant  application  knowledge.  In  large  real-time  programs,  this 
complexity  is  overwhelming.  On  the  other  hand,  testing  suffers  from  lack  of 
rigor.  Unless  careful  analysis  shows  that  the  test  cases  generate  a 
relationship  to  the  worst  case  execution  time  for  the  code,  then  these  results 
are  not  necessarily  legitimate  boimds.  Possibly,  the  derived  times  may  bound 
the  execution  time  most  of  the  time.  This  qualification,  though,  is  not 
quantifiable  and  the  consequences  of  failure  may  be  too  severe  to  rely  on  it. 
Thus,  we  learn  from  these  techniques  a  need  for  analytic  simplicity  and 
logical  rigor.  Structured  programming  in  higher-level  languages  was 
developed  to  simplify  the  logical  complexity  of  unstructured  and  assembler 
code.  Several  researchers  have  turned  toward  analysis  of  the  source  code  for 
timing  information  to  benefit  from  its  reduced  complexity. 

Mok’s  annotation  technique  [11]  automates  the  hand  analysis  process 
described  by  Knuth.  Like  Knuth’s  technique  it  is  limited  to  the 
implementation  and  post-implementation  phases.  The  developer  annotates 
the  program.  The  annotated  program  is  fed  to  a  set  of  timing  analysis  tools 
and  to  a  special  compiler.  The  compiler  is  modified  only  in  that  it  adds  labels 
to  various  assembly  instructions  in  the  code  generation  phase.  These  labels 
do  not  affect  the  final  object  code  that  the  assembler  stage  generates.  Besides 
feeding  the  assembler  stage,  the  annotated  assembly  code  is  also  fed  to  the 
timing  analysis  tool.  Using  the  labels,  the  annotated  source  code  and 
assembly  code  are  merged.  The  developer  then  works  interactively  with  the 
timing  tools  to  generate  timing  information  about  the  program. 
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Many  of  the  more  advanced  techniques,  including  Haase’s  guarded 
commands  and  PARCs  [9],  Halang’s  extensions  to  the  PEARL  programming 
language  [10],  Puschner  and  Koza’s  MARS-C  language  [12],  and  Kenney  and 
Lin’s  FLEX  [13],  are  based  on  theoretical  languages  or  language  extensions 
that  are  not  used  in  practice.  Thus,  they  are  not  portable  as  defined  nor  do 
they  use  Ada.  Many  of  these  extensions  could  be  translated  to  Ada;  however, 
Ada  supersets  are  disallowed  in  Department  of  Defense  projects  and  are 
discouraged  in  general.  This  raises  the  restriction  that  the  technique  not 
require  language  extensions  or  particular  code  generation  behavior  beyond 
that  stated  in  the  language  definition.  It  is  important  to  note  that 
annotations  like  those  used  by  Mok  satisfy  this  restriction.  Although  they 
require  support  in  the  compiler,  they  do  not  affect  the  language  definition. 

Glicker  and  Hosch  describe  a  system  that  uses  symbolic  execution  to 
model  the  behavior  of  Ada  programs  [14].  It  first  determines  the  best  and 
worst  case  threads  of  execution  through  the  Ada  task  system  given  a  set  of 
preconditions.  These  threads  are  then  measured  directly  using  the  target 
architecture.  This  method  shows  some  promise  although  it  can  only  apply  to 
completed  programs.  Its  success  hinges  on  the  adequacy  of  the  symbolic 
execution  stage.  Tracing  all  threads  through  a  program  is  naturally  an  O(e^) 
time  activity.  Good  branch-and-bound  heuristics  must  be  applied  to  keep  the 
process  tractable. 

Several  of  these  techniques  share  common  features.  The  most  prevalent 
of  these  is  analysis  of  the  programming  language  constructs  themselves  to 
reason  about  the  timing  behavior  of  the  program.  This  concept  is  distilled  by 
Shaw  in  his  timing  schema  approach.  Shaw’s  work  is  done  in  C.  Ada  has 
several  language  constructs  that  make  timing  analysis  easier  and  several 
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more  complex  constructs  than  the  simple  statements  and  expressions  allowed 
by  C. 

In  summary,  existing  techniques  are  generally  not  applicable  to  large  real¬ 
time  Ada  projects.  Furthermore,  they  are  not  applicable  throughout  the 
development  process.  Mok’s  annotations  could  be  extended  to  Ada’s 
sequential  language  constructs.  Its  biggest  short-coming  is  reliance  on 
compiler  support.  It  also  raises  some  configuration  management  hurdles  in 
ensuring  that  the  data  under  analysis  comes  from  the  current  code  baseUne. 
Jumping  these  hurdles  is  straight-forward  with  careful  process  management. 
Shaw’s  timing  schema  grant  the  developer  less  flexibility  than  Mok’s  for 
timing  analysis,  but  do  not  rely  on  compiler  support.  Both  techniques  must 
be  extended  to  handle  Ada  tasking  constructs.  This  thesis'  technique 
develops  Shaw’s  timing  schema,  adding  tasking  support,  while  allowing  some 
compiler-independent  annotations  or  assertions. 

Schema  Based  Timing  Analysis 

Timing  schema  are  based  on  Hoare  logic  [16].  Hoare  logic  uses  the 
notation  {P}S{Q}  to  mean  that  given  the  conditions  P  immediately  prior  to 
execution  of  S  results  in  condition  Q  upon  completion  of  execution.  An 
inherent  assumption  is  that  S  does,  in  fact,  complete.  The  change  in  time 
from  executing  statement  S  can  be  described  with  Hoare  logic  as  follows 
{rt  =  x}S{rt  =  X  +  ^(S)},  where  rt  represents  the  time,  x  represents  the  value  of 
rt  immediately  prior  to  execution  of  S  and  ^  is  a  function  which  returns  the 
execution  time  of  S.  The  first  application  of  Hoare  logic  like  this  is  in  a  paper 
by  Mary  Shaw.  [17] 


The  function  t  has  as  its  domain  the  set  of  all  possible  programs  and  as  its 
range  the  non-negative  real  numbers.  A  definition  of  t  can  consist  of  a  set  of 
axioms  {(S,t)}  relating  all  programs  to  their  execution  time.  Since  there  are 
infinite  programs,  this  approach  cannot  always  work.  However,  t  can  be 
described  with  a  finite  set  of  rules  for  generating  the  infinite  set  of  relations 
above.  This  set  of  rules  is  a  schema. 

The  above  is  flawed  in  that  t  in  the  rule  set  must  be  a  single  value  to 
define  a  well-formed  fimction.  For  a  single  execution  of  a  program,  it  will 
indeed  take  a  specific  time  value  to  execute.  In  fact,  the  execution  time  of  a 
given  program  may  vary  from  one  execution  to  another.  There  exist  many 
reasons  for  this  including  differences  in  inputs,  differences  in  machine  state 
at  the  start  of  execution,  inconsistencies  in  the  machine  clocking  mechanism 
and  differences  in  the  machine-language  instantiation  of  the  program. 
Further  discussion  of  these  variabilities  will  occur  in  the  section  on  compiler 
analysis  in  Chapter  3.  Let  ^’(S,x)  be  the  function  which  retiuTis  the  single 
value  for  the  execution  time  of  S  as  indexed  by  x  £  {all  possible  execution 
conditions}.  A  more  correct  model  of  t,  then,  may  be  a  random  variable;  thus  t 
is  a  mapping  from  programs  to  random  variables.  It  is  adequate,  however,  to 
model  t  as  a  closed  interval  T  =  [^mm,  tmax\  where  P[f’(S,x)  £  T]  =  1  for  all  x. 
Therefore,  timing  analysis  of  a  program  S  consists  of  computing  US).  This  is 
done  using  a  schema  which  generates  a  rule  computing  a  closed  time  interval, 
T,  for  S. 

Arithmetic  and  logical  operations  on  values  of  T  use  a  form  of  interval 
arithmetic.  Additive  operations  are  simply  applied  component-wise. 
Multiplicative  operations  are  distributed,  T  op  x  =  [tmin  op  x,  tmax  op  x]. 
Relational  operations  are  applied  to  the  tmax  component  first  since  the  worst- 
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case  is  the  more  important  in  real-time  analysis.  If  the  tmax  components  are 
equal,  then  comparison  of  the  tmin  components  determines  the  result. 

The  schema  are  defined  for  the  grammatical  elements  of  a  language.  For 
instance,  the  schema  for  an  if-statement,  ‘Itif-statement],  might  be; 

'2[if-statement]  =  [10,15]  +  'Z[boolean-e:qp]  +  [imn(([4,6]  +  CZ[then-part]), 

([2,4]  +  '7[elae-part])),  max(([4,6]  +  'll  then-part]),  ([2,4]  +  'Ztelse-part]))] 
v^ere  l£-statement  :  t=  if  boolean-exp  then  then-part  else  else-peurt; 

The  schema  rule’s  definition  consists  of  constant  parts  like  [10,15]  and 
recursive  invocation  of  other  schema  rules.  These  constant  parts  represent 
some  basic  computation  to  provide  the  language  behavior  for  that  construct. 
The  logical  basis  of  the  above  rule  is  that  the  system  computes  the  boolean 
expression  (boolean-exp)  and  spends  time  branching  on  the  result  ([10,15]). 
The  branch  with  the  bigger  execution  time  is  the  worst  case  choice  and  the 
lesser  execution  time  is  the  best  case  choice.  The  branch  execution  time 
consists  of  the  time  spent  executing  the  statements  in  the  branch  (then-part 
or  else-part)  and  time  spent  rejoining  the  main  execution  stream  ([4,6]  or 
[2,4]). 

Primitive  times  like  the  constant  parts  described  above  are  dependent  on 
the  underlying  system  consisting  of  the  hardware,  operating  system,  and 
compiler.  The  exact  value  of  the  primitives  will  differ  from  one  underlying 
system  to  another,  but  it  is  always  present  in  the  schema  since  its  existence 
derives  from  some  computational  need  in  the  language  definition.  It  may  be 
possible  for  a  particular  system  to  compute  a  particular  primitive  in  time 
[0,e],  for  a  very  small  e  >  0,  using  special  hardware  or  subsuming  it  in  other 
primitives. 

Eventually,  any  given  program  will  reduce  through  the  schema  rules  to  a 
sum  of  primitive  times.  This  is  akin  to  parsing  the  language  where  non¬ 
terminals  in  the  grammar  are  similar  to  schema  rules  and  terminals  are 
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similar  to  primitive  times.  Computing  the  sum  gives  the  resulting  execution 
time  of  the  code  sequence.  One  inherent  assumption  throughout  this 
discussion  has  been  that  the  program  has  a  single  thread  of  execution.  With 
multiple  threads,  timing  schema  analysis  must  be  applied  to  each  thread. 

The  relationship  between  the  threads  must  be  addressed  with  other 
mechanisms.  These  mechanisms  will  be  discussed  in  the  next  two  chapters. 

Scheduling  Analysis 

Scheduling  is  one  of  the  main  problems  in  the  area  of  real-time  systems. 
The  problem  is  to  determine  if  a  given  set  of  tasks  can  meet  all  of  their 
deadlines  on  a  given  set  of  processors.  Tasks  in  the  sense  of  scheduling  are 
described  as  a  triple  {a ,  c,  o?}  where  a  is  the  arrival  time,  c  is  the  execution 
time  required  to  complete  the  task,  and  d  is  the  deadline  for  the  task  [18]. 
Knowing  the  execution  time  of  a  task,  then,  is  critical  to  conducting 
scheduling  analysis. 

This  notion  of  a  task,  however,  is  abstract.  An  Ada  task,  on  the  other 
hand,  is  a  concrete  programming  construct.  The  two  concepts  do  not 
necessarily  relate  directly.  Consider  an  event-driven  system.  The  response  of 
the  system  to  a  certain  input  event  is  a  task  for  scheduling  purposes.  Its 
arrival  time  is  the  time  of  the  event.  Its  deadline  is  the  response  time 
specified  for  the  system  (derived  from  physical  requirements  or  allocation  of 
other  timing  requirements).  The  final  component  is  the  execution  time. 

While  the  first  two  components  are  commonly  defined  in  the  system 
requirements  or  description,  the  execution  time  results  from  design  and 
implementation.  Timing  analysis  is  the  technique  to  determine  the  execution 
time. 
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During  the  requirements  and  early  design  phase,  the  software  analyst 
should  determine  the  events,  deadlines,  and  event  arrival  scenarios  the 
system  will  handle.  Scheduling  analysis  is  used  to  determine  if  the  system 
can  satisfy  its  constraints.  Thus,  execution  times  must  be  predicted  as  early 
in  the  design  as  possible.  As  design  progresses  and  implementation  begins, 
the  system  model  is  refined.  Scheduling  analysis  continues  to  determine  if 
the  current  model  is  viable.  Thus,  execution  timing  analysis  must  continue 
and  hopefully  improve  through  the  process.  During  validation,  scheduling 
analysis  with  inputs  from  timing  analysis  is  used  to  determine  whether  or 
not  the  system  as  implemented  can  satisfy  its  constraints  in  all  cases. 

Testing  is  not  satisfactory  in  many  cases  since  it  may  not  test  the  worst  case 
conditions  that  may  be  encountered. 

Scheduling  analysis,  however,  depends  on  the  scheduling  strategy 
implemented  by  the  system.  A  rate  monotonic  system  can  be  implemented 
using  Ada  tasking  and  priorities.  Ada,  however,  is  currently  prone  to  priority 
inversion  [19].  Many  scheduling  approaches  are  available  in  any 
programming  language  by  implementing  a  scheduler  as  part  of  the  system. 
Cyclic  executives  are  also  popular  with  real-time  developers  [20]. 

In  summary,  it  is  important  to  keep  distinct  the  concept  of  scheduling 
tasks  and  the  Ada  task  constructs.  While  it  is  possible,  Ada  tasks  do  not  map 
well  to  current  scheduling  strategies.  Scheduling  strategies  can  be  built  into 
a  system,  however,  and  Ada  tasks  used  within  the  implementation  of  that 
system  separate  from  scheduling  policies. 
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Discussion 

Timing  Analysis  using  Shaw’s  schema  techniques  and  Ada  satisfies  the 
stated  objectives.  When  used  with  scheduling  analysis,  timing  analysis  can 
be  used  to  show  that  a  system  satisfies  its  real-time  requirements. 

Regardless,  timing  analysis  can  characterize  program  timing  behavior  to  give 
system  developers  information  for  design,  implementation  and  verification 
decisions. 

Several  existing  timing  analysis  techniques  only  apply  to  completely 
implemented  systems.  The  timing  schema  approach  outlined  above  can  be 
used  with  an  Ada  program  design  language  (PDL)  to  provide  timing  analysis 
throughout  the  development  and  with  varying  stages  of  system  completion. 
Tliis  lets  the  developer  identify  and  track  or  correct  problems  early  when  they 
are  cheapest  to  fix. 


Chapter  III 


Timing  Schema  and  Events 


Introduction 

The  first  step  in  timing  analysis  is  transforming  the  Ada  programs  into 
timing  graphs.  The  transformation  is  based  on  a  DIANA  representation  of 
these  programs.  A  schema  rule  is  defined  for  each  type  of  DIANA  node.  The 
resulting  timing  graph  may  be  as  simple  as  a  single  edge,  representing  a 
simple  sequential  program.  It  may  also  be  very  complex  containing  several 
nodes  and  branching  alternatives.  The  generation  of  these  graphs  are 
discussed.  The  analy'’^  has  some  control  over  the  graphs  through  the  use  of 
assertions. 

DIANA  Representation  of  Ada  Programs 

DIANA  is  an  abstract  data  type  for  representing  Ada  programs  [7].  A 
DIANA  object  is  mathematically  modelled  as  an  attributed  tree.  The  tree 
represents  a  normalized  form  of  a  corresponding  Ada  program.  It  also 
guarantees  that  a  given  Ada  object  has  only  one  defining  occurrence;  and  the 
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defining  occurrence  is  an  attribute  of  the  other  occurrences.  Using  DIANA 
takes  care  of  the  complicated  Ada  parsing  and  static  semantic  analysis.  The 
tree  model  is  easily  manipulated. 

A  given  node  of  the  DIANA  tree  is  defined  in  terms  of  the  attributes  it  has. 
A  node  has  a  structural  arity  in  the  set  {0,l,2,3,n}  and  has  zero  or  more 
lexical,  semantic,  and  code  attributes.  Additional  attributes  may  exist  as 
needed  by  an  application;  however,  these  are  not  standard  and  cannot  be 
relied  on.  The  structural  arity  denotes  the  branching  of  each  node  to  other 
nodes.  The  other  attributes  may  provide  numeric  or  textual  information  or  be 
semantically  related  nodes.  By  sharing  identical  nodes,  the  tree  becomes  a 
directed  acyclic  graph  (DAG).  The  DAG  model  is  identical  to  the  tree  model 
except  that  it  allows  replication  to  be  eliminc  "ed. 

For  example,  the  simple  program  below  simulates  rolling  x  n-sided  dice 
where  x  and  n  are  supplied  by  the  caller.  This  converts  to  the  DIANA  DAG 
described  following  it.  The  format  for  a  DAG  node  is 

namei  j  node  type  [  attributes  ).  Attributes  are  juxtaposed  pairs  of  the  form 
attribute  name  attribute  vaiue.  Multiple  attributes  are  Separated  by  semicolons. 


function  ROLL_DICE  (NUM_SIDES,  NUM_DICE  :  in  INTEGER) 
return  INTEGER  is 

subtype  DIE_RANGE  is  INTEGER  1  ..  NUM_SIDES; 

A_DIE  :  DIE_RANGE; 

TOTAL  :  INTEGER  :=  0; 
begin 

for  A_ROLL  in  1  . .  NUM_DICE  loop 

A_DIE  :=  INTEGER (RANDOM  *  NUM_SIDES)  +  1; 

TOTAL  ;=  TOTAL  +  A_DIE; 
end  loop; 
return  TOTAL; 

end  ROLL  DICE; _ 


Figure  1:  Sample  Ada  Program 


Nodes  with  names  like  PDx  are  part  of  the  Ada  package  “Standard”  provided  as  part  of 
the  compiler  environment.  These  names  are  used  consistently  with  the  example  in  [7]. 


Al  :  compunit 
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[  as_pragina_s  ^A2 ; 
a9_context  ^A3 ; 
as  unit  body  ''A4  ] 


A2 

pragma_s 

[  as_list  <  >  ] 

A3 

context 

[  as  list  <  >  ] 

A4 

subprograiii_body 

[  asdesignator  ^A5 ; 
as_header  '' A6 ; 
as  block  stub  ''A7  ] 

A5 

function_id 

[  lx_synu:ep  "ROLL_DICE"; 
sm_spec  ^A6 
sm_body  ''A7 
sm  location  void  ] 

A6 

• 

function 

I  as_param_s  ''AS 
as_neme  ''A13  ] 

A7 

• 

block 

[  as  item  s  ''A14; 
as_stm_s  ''A29; 
as  alternative  s  ^A54  ] 

AS 

: 

param  s 

[  aslist  <  ^A9  >  ] 

A9 

• 

in 

[  as  id  s  ''AlO; 
as_naine  ^A13; 
as  exp  void  void  ] 

AlO 

; 

id  s 

[  as  list  <  ^All  ^A12  >  j 

All 

• 

in_id 

[  lx_syinrep  "NUM_SIDES"; 
sminitexp  void; 
sm  obj  type  ^PD9  ] 

A12 

• 

in_id 

[  lx_symrep  "NUM_DICE"; 
sm_init_exp  void; 
sm_obj_type  ^PD9  ] 

A13 

• 

u  sed_naine_id^ 

[  lx_symrep  "INTEGER"; 
sm  defn  ^PDS  ] 

A14 

item  3 

1  as  list  <  ''A15  ^A16  ''A17 

A15 

subtype 

[  as_id  ^AIS; 

as  constrained  ^A19  ] 

A16 

var 

(  as_ids  ^A23; 

as  type  spec  ^ A2  5 ; 
asob jectdef  void  ] 

A17 

var 

[  asids  ^A26; 

astypespec  ^ Al 3 ; 
as_ob ject_def  ^A2S  ] 

A18 

subtypeid 

[  lx_symrep  "DIE_RANGE"; 
sm_type  spec  ''A19  ] 

A19 

constrained 

[  asname  "A13; 

as_constraint  ^A20; 
sm_type_struct  ^A19; 
sm_base_type  ''PD9; 
sm  constraint  ^A20  ] 

A20 

range 

[  as_expl  ''A21; 
as_exp2  ''A22  ] 

A21 

nuineric_literal 

(  Ixnumrep  "1"; 
sm_exp_type  ^PD9; 
sm  value  1  ] 

A22 

used_ob ject_id 

[  lx_symrep  "NUM_SIDES"; 
smexptype  ^PD9; 
sm  defn  ^All  ] 

A23 

; 

id  s 

f  as  list  <  ^A24  >  1 

Note  that  this  node  is  heavily  reused  in  the  structural  DAG.  This  is  not  surprising  since 
it  represents  the  type  integer 
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A24 

var_id 

[  lx_symrep  "A_DIE"; 
smobjtype  ^A19; 
sm_address  void; 
sm  obi  def  void  1 

A25 

• 

used_name_id 

[  lx_syinrep  "DIE_RANCT:" 
sm  defn  ''A18  ] 

T 

A26 

: 

id  s 

[  as  list  <  ''A27  >  ] 

A27 

varid 

[  lx_3ymrep  "TOTAL"; 
sm_obj_type  *PD9; 
sm_address  void; 
sm  obj  def  ''A28  ] 

A28 

nuineric_literal 

[  Ixnumrep  "0"; 
sm_exp_type  ''  PD  9 ; 
sm  value  0  ] 

A29 

s 

stir.  3 

[  as  list  <  ^A30  ^A53  > 

] 

A30 

t 

loop 

[  as_iteration  ''A31; 
as  stm  s  ^A36  ] 

A31 

• 

for 

[  as  id  ''A32; 

as  dscrt  range  ''A3 3  ] 

A32 

iterationid 

[  lx_symrep  "A_ROLL" ; 
sm  obj  type  ''PD9  ] 

A3  3 

constrained 

[  as_name  ''A13; 

as  constraint  ''A34; 
sm  type  struct  ''A3  3; 
sm_base_type  ''PD9; 
sm  constraint  ''A3  4  ] 

A3  4 

• 

range 

[  as_expl  ''A21; 
as_exp2  ^A35  ] 

A3  5 

used_object_id 

(  lx_symrep  "NUM_DICE"; 
sm_exp_type  ^PD9; 
sm  defn  ''A12  ] 

A3  6 

; 

stm  s 

[  as  list  <  •'A37  ^A49  > 

] 

A3  7 

assign 

[  as_name  ^A38; 
as_exp  *A39  ] 

A3  8 

used_ob ject_id 

[  Ixsymrep  "A_DIE"; 
sm_exp_type  ''A19; 
sm  defn  *A24  ] 

A39 

function_calL 

[  asname  ^a40; 

as_param_assoc_s  ''A41 

1 

A40 

usedbltnop 

I  Ixsymrep  "+"; 

smoperator  BINARy_PLUS  ] 

A41 

: 

param_assoc_s 

[  as_list  <  ^A42  "A21  > 

1 

A42 

conversion 

[  asname  "AlS; 
as_exp  *A43  ] 

A43 

function_call 

[  asname  ^A44; 

as_param_assoc_s  ''A45 

1 

A44 

used_bltn_op 

[  Ixsymrep  " * " ; 

sm_operator  MULTIPLY 

] 

A45 

param  assoc  s 

[  as  list  <  ''A46  ^A22  > 

] 

A46 

function_call 

[  as  name  ''A47; 

as_param_assoc_s  ^A48 

] 

A47 

' 

usedob ject_id 

I  lx_3ymrep  "RANDOM" ; 
smexptype  . . . ; 
sm  defn  ... 

A48 

param  assoc  s 

[  as  list  <  >  ] 

This  is  an  external  function  with  nodes  outside  the  immediate  program.  These  are 
elided  for  conciseness. 
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A49  : 

assign 

[  as  name  ''A50; 
as_exp  ^A51  ] 

A50  : 

used_ob jectid 

[  Ix  synurep  "TOTAL"; 
sm_exp_type  ''PD 9; 
sm  defn  ^A27  ] 

A51  : 

function_call 

[  as_naine  ''A40; 

as jjaram  assoc  s  ''A52 

1 

A52  ; 

param  assoc  s 

[  as  list  <  ''A50  ^A38  > 

1 

A53  ; 

return 

f  as  exp  void  ''A50  1 

A54  : 

alternative  s 

r  as  list  <  >  1 

Figure  2:  DIANA  Representation  of  the  sample  program 


Figure  3;  DAG  of  structural  DIANA  nodes  for  Sample  Program 


Timing  Analysis  Transformation  Algorithm 


The  basic  algorithm  is  to  transform  the  DIANA  object  representing  an 
Ada  program  into  a  graph.  The  edges  of  the  graph  represent  sequential 
portions  of  the  Ada  program.  The  vertices  represent  potential  context 
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switches.  The  graph  is  built  by  traversing  the  tree  depth-first  or  “bottom-up.” 
As  each  node  is  traversed  a  subgraph  is  created  based  on  the  type  of  node  and 
the  subgraphs  of  its  children.  A  simple  implementation  is  to  apply  the 
schema  function  to  the  root  node  and  using  the  recursive  nature  of  the 
schema  to  traverse  the  tree.  The  traversal  of  a  node  is  dependent  on  its  type 
and  structural  attributes  only.  Its  schema,  however,  may  use  semantic 
information  in  computing  bounds  and  values. 

The  timing  graph  created  by  this  process  consist  of  edges  weighted  with 
execution  times  and  vertices  to  connect  edges.  Multiple  edges  leaving  a 
single  vertex  represent  branching  dependent  on  task  synchronization.  When 
constructed  into  a  system  network,  only  one  branch  in  an  instance  will  be 
utilized;  the  others  are  discarded. 

A  delay  edge  denotes  a  constraint  that  a  certain  time  must  pass  between 
two  vertices  before  execution  can  continue.  A  context  switching  node  is  so 
marked  where  a  context  switch  may  occur.  This  is  done  solely  for  the 
purposes  of  calculating  the  potential  number  of  context  switches  in  the 
resulting  system  model. 

Timing  Schema  for  DIANA  Objects 

The  170  different  DIANA  node  types  are  listed  below.  Each  entry  includes 
the  structural  and  key  semantic  attributes  as  well  as  the  schema  for 
computing  the  worst  and  best  case  time  bounds  for  that  node  type.  Several 
auxiliary  functions  are  used  to  simplify  the  schema.  These  include: 

•  Store(Node):  Determines  the  proper  primitive  time  to  store  a  value 
in  an  object  by  examining  the  type  of  the  object. 

•  Access(Node):  Determines  the  proper  primitive  time  to  access  a 
value  in  an  object  by  examining  the  type  of  the  object. 
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•  Init(Node):  Determines  the  proper  primitive  time  to  initialize  a 
value  in  an  object  by  examining  the  type  of  the  object. 

•  Save:  This  function  updates  the  library  of  computed  timing  graphs 
with  the  graph  computed  for  some  subprogram,  task,  package,  or 
generic  declaration.  These  graphs  are  used  by  the  Insert  function 
or  by  the  analyst  in  constructing  a  system  network  as  described  in 
the  next  chapter.  Save  “returns”  the  value  [0,0];  that  is,  in  storing 
the  graph  designated,  this  graph  is  not  included  in  the  computed 
time  of  the  declaration  block  in  which  it  occurs.  This  follows  since  it 
is  not  executed  at  time  of  declaration.  Some  elaboration  time  may 
be  included  in  the  schema  in  addition  to  the  save,  however.  This 
does,  indeed,  execute  during  elaboration  of  the  execution  block. 

•  Stop:  Halt  computation  within  an  enclosing  stm_s  type  node.  This 
occurs  when  an  unconditional  change  in  control  flow  is  encountered 
in  a  sequence  (i.e.,  return,  goto,  or  imconditional  exit). 

•  Abort:  Ignore  this  path  (stm_s  node)  since  it  contains  a  raise  or 
abort  statement.  Currently  raise  and  abort  are  restricted  to  use 
with  error  conditions.  Error  conditions  are  not  analyzed  by  the 
technique  at  this  time. 

•  Insert(Name):  Insert  the  graph  for  a  subprogram  at  this  point  in 
the  current  graph.  Look  for  a  recursion  assertion  if  it  is  the  same 
subprogram. 

•  Node(Name):  End  the  current  edge.  Create  a  vertex.  Start  a  new 
edge(s).  With  rendezvouses,  the  node  will  be  linked  to  a 
corresponding  node  in  another  task,  so  one  edge  will  be  missing. 

•  Delay(Duration):  Create  a  pair  of  nodes  with  a  delay  edge  between 
them  of  the  duration  given. 

•  Activate(Task[s]):  Create  a  context-switching  node  at  this  point 
preceded  by  the  timing  primitive  P(  activation)  and  attach  Task[s] 
(as  well  as  continuing  the  current  thread). 

•  Queue- Activate(Task[s]):  Like  Activate  except  that  the  node  is 
inserted  after  completing  all  processing  of  the  current  declarative 
block. 

•  ConstraintCheck(Node):  Determine  the  proper  primitive  time  for  a 
constraint  check  on  the  type  of  the  given  node. 

•  Print(String):  Print  the  given  string  on  the  analyzer’s  error  output 
stream. 

•  Range(DSCRT_RANGE):  Determines  the  lowest  and  highest 
possible  values  of  the  range. 


Schema 

abort 

1 

Abort  —  abort  statements  are  treated  as  errors  at  this  point  and  are  not 
candidates  for  a  min  or  max  path. 

accept 

3 

P(accept)  +  Node(“start  “&as_name) ;  Node(“Begin’’&as_name)  + 
P(rendezvous)  +  T(a3_8tm_s)  +  P(accept_end)  +  Node(“end  ‘‘&as_name) 

access 

1 

T(as_cons  trained) 

address 

2 

[0,0]  —  representation  clause  affects  compilation  only 

aggregate 

n 

(  y  T(a8  li8t[i])^  +  Store(sm  exp  type) 

} 

2 

[0,0] "  representation  clause  affects  compilation  only 

aU 

1 

[0,0]; 

allocator 

1 

T(as_exp_constrained)  + 
if  8m_exp_type  =  ta3k_spec 
then  Activate(task) 

else  Store{sm_exp_type)  +  P(allocate_mem(Size(sm_exp_type)) 

Note;  Records  and  arrays  with  task  components  need  a  hybrid  of  the  if- 
statement  above  to  apply. 

alternative 

2 

--  subsumed  in  schema  for  case  node 
-  ignored  as  attribute  of  exception  part  of  blocks 

altemative_a 

n 

-  subsumed  in  schema  for  case  node 

--  ignored  as  attribute  of  exception  part  of  blocks 

and then 

0 

P(and_then) 

TBwsmam 

0 

[0,0]  --  identifier  “symbol  table”  entry 

array 

2 

T(aa_dscrt_range_a)  +  T(as_constrained) 

assign 

2 

T(as_name)  +  T(as_exp)  +  Store(a3_name)  +  ConstraintCheck(as_name) 

+  if  as_exp  =  u8ed_object_id  then  Acce88(a8_exp.8m_exp_type)  else  [0,0] 

assoc 

2 

T(as_actui»l) 

attrjd 

0 

[0,0] "  identifier  “symbol  table”  entry 

attribute 

2 

T(as_name)  +  P(“attr_”  &  as_id.8m_defn.lx_3ymrep) 

-  attribute  execution  times  are  pre-defined 

iTfTTiVtPfTSHHI 

2 

T(a8_exp)  +  T(a8_name)  -  as^name  is  a  node  of  type  attribute 

binary 

3 

[T(as_expl),  T(a8_expl)  +  T(as_exp2)]  +  T(as_binaTy_op) 

block 

3 

T(a8_item_8)  +  T(as_8tm_s) 

--  as.  alternative  s  represents  exception  handlers 

box 

0 

[0,0]  —  generic  subprogram  formal  option 

case 

2 

T(a8_exp)  +  P(case)  +  [min(choice8),max(choices)] 

choices  =  {T(as_altemative_s.as_hst(n].as_stm_s) :  1  ^  n  ^  1  as_listl} 

-  as_altemative_s.as_hst[n].as_choice_8  must  be  static  and  is  ignored 

choice_s 

n 

n 

2  T(asjist[i]) 
i=l 

code 

2 

T(as_exp)  -  machine  dependent  code  insertion 
-  execution  time  bounds  must  be  specified  with  a  time  assertion 

comp_id 

0 

[0,0]  ”  identifier  “symbol  table”  entry 

conip_rep 

3 

[0,0]  —  representation  clause  affects  compilation  only 

comp  rep  _s 

n 

[0,0]  -  representation  clause  affects  compilation  only 

comp_unit 

H 

T(  as_imit_body ) 

-  as_contexl  and  as_pragma_s  set  up  environment  only 

compilation 

n 

(map  T  as.Ust)  =  T(hd(as_list));(map  T  tKasJist)) 

-  list  of  all  compilation  units  in  the  system 

cond_clause 

2 

”  subsumed  in  schema  for  “iP  node 

cond_entry 

2 

P(cond_entry)  +  Nodel  +  Delay(e)  +  T(as_stm_s2)  +  Node2; 

--  Delay(e)  prejudices  choice 

Nodel  +  TXas.stm  si)  +  Node2;  —  first  stm  is  entry_call 

const_id 

0 

[0,0]  ”  identifier  “symbol  table”  entry 

constant 

3 

2 

T(a8_constraint) 

1  context  1 

1  ^ 

[0,0]  --  set’s  up  environment,  no  cost 

context 


conversion 

2 

decl_8 

n 

def_char 

0 

def_op 

0 

deferred_coiL8tant 

2 

delay 

1 

derived 

1 

d8crmt_aggregate 

■ 

0 

3 

d8crmt_var_8 

n 

d8crt_range_8 

■ 

entry 

2 

entry_call 

2 

entryjd 

0 

enum id 

0 

n 

1  exception 

2 

0 

exit 

2 

exp_9 

n 
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case  a8_name.8m_defii.8m_type_spec,  as_exp.8m_iype_8pec 
real  to  int;  P(convert_float2int)  or  P(convert_fixed2mt) 
int  to  real:  P(convert_int2float  or  P(convert_mt2fixed) 
real  to  real;  P(convert_fixed2float)  or  P(convert_float2fixed) 
derived ;  P(convert_derived) 
array:  P(convert_array) 

others;  [0,0]  -  not  changing  base  type 

+ 

if  subtype 

then  Con8traint_Check(8m_exp_tyj>e)  else  [0,0] 

+  T(a8_exp) 

n 

2^T(as_list{i])  +  Init(a8_li8tCi]) 

[0,0];  -  never  called  since  enum_literal_s  is  always  [0,0] 

Access  =  P(num_acceas) 

[0,0]  -  operator  “symbol  table”  entry 

[0,0]  —  any  coat  will  be  incurred  with  full  declaration 

T(as_exp)  +  P(delay) 

+  Delay((8m_value  or  maxCsubtype  range))  +  P(delav_cap)) 

T(aa_con8  trained) 

n 

2  T(aa_Uat[i]) 
i=l 

[0,0]  —  identifier  “symbol  table”  entry 

T(aa_obiect_def) 

n 

y  T(aaji8t(i]) 
i=l 

n 

^T(as_list[i]) 

T(as_dscrt_range_void)  +  T(a8_param_8) 

T(a8_name)  +  T(sm_nonnali2ed_param_8)  +  P(queue_entry) 

+  Node(“start  “&a8_name)  ;  Node(“end  “&as_name)  +  [0,0] 

[0,0] "  identifier  “symbol  table”  entry 

[0,0];  -  never  called  since  eniun_literal_8  is  always  [0,0] 

[0,0]  —  list  of  def_char  and  enumjd;  each  static  so  [0,0]  elaboration  time 

[0,0]  ••  declares  exception  names 

[0,0]  -  identifier  “symbol  table”  entry 

if  a8_exp_void  =  void  then  Stop*  else  T(as_exp_void) 

-  computes  condition,  but  doesn’t  affect  number  of  loop  iterations 

-  *a  branch  containing  unconditional  exit  can  only  be  executed  once, 

-  so  normally  cannot  be  worst  case  branch^ 

n 

^^TXasJiatti]) 

T(as_range_void)  --  as_exp  is  static 

T(a8_range_void)  ~  a8_exp  is  static 

T(a8_d8crt_range) 

[0,0]  --  place  holder  for  generic  type  parameters 

[0,0]  -  place  holder  for  generic  type  parameters 

[0,0]  -  place  holder  for  generic  type  parameters 

[0,0]  -  place  holder  for  generic  type  parameters 

TXa8_param_8) 


Can  be  best  case,  however.  F\irthermore,  unusual  conditions  such  as  an  exit  branch 
which  is  much  more  computationally  intensive  than  other  branches  through  the  loop  or 
a  loop  which  only  executes  a  small  number  of  times  may  be  a  worst  case.  A  more 
thorough  analysis  may  determine  this. 
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if  as_name  is  U8ed_bltn_id  or  used_bltii_op  then 
check  sm_value  for  static  expression  and  treat  as  folded  constant 
if  one  exists,  otherwise  Pibltn)  +  T(sm_nonnalized_param_s) 
else 

P(fiinction_call)  +  T(8m_normalized_param_s)  +  Insert(as_name) 

+  P(fiinction_end) 

-  sm_normalized_parani_3  includes  default  params 

[0,0]  —  identifier  “symbol  table”  entry 

save  id(a8_id)  =  T(a8_generic_header) 

-  a8_generic_param_8  is  used  to  define  quasi-primitives  to  be  replaced 
with  actual  times  when  instantiated. 

n 

T(a8_li8t[i]) 

[0,0]  —  identifier  “symbol  table”  entry 

n 

2)  T(aa_liat[i]) 
i=l 

Print(“Waming:  Unstructured  statement  <goto>  cannot  be  analyzed”) 

-f-  Stop 

“  if  a  forward  goto,  this  will  compute  correctly;  if  it  causes  a  loop,  then 
the  analysis  is  bad. 

[0.0]; 

choices  =  "{  f  51  T(as_list[i].as_exp_void)  +  P(el8e)'|  + 

Tfas_li8ttn].a8_8tm_8)  :  Isns  1  asjist  1  } 

P(if)  +  [niin(choice8)4nax(choices)] 

if  a8_exp_void  *  void 

then  T(as_exp_void)  +  P(default_param) 

P(in) 

[0,0] "  caimot  have  default  parameters 

[0,0]  -  identifier  “symbol  table”  entry 

[0,0]  -  as  name  is  an  uconstrained  type. 

T(aa_name)  +  T(a8_exp_8) ; 

n 

^  T(a8_li8t[i]) 

T(a8_generic  assoc  s) 

T(as_range); 

n 

^TCas_li3t(i)) 

[0,0] "  identifier  “symbol  table”  entry 

[0,0]  —  identifier  “symbol  table”  entry 

T(as_stm) 

if  asjteration  =  void  or  asjteration  =  while 
then  T(as_iteration)  +  P(loop)  + 

LOOP_ASSERTION  *  (T(a8_8tm_8)  +  T(as_iteration)  +  P(iter)) 

-  P(iter)  +  P(loop_end) 

"  if  no  loop  assertion  then  if  no  nodes  in  a8_stm_s 
then  print  “Unbounded  Loop”  +  Stop 
else  unroll  as  far  as  necessary 
else  TXasJteration)  +  P(for_!'v>p)  + 

Range(a8_iteration.a8_d8crt_range)  *  (T(a8_8tm_s)  +  P(for_iter)) 

-  P(for  iter)  +  P(for  end) 

[0,0] 

[0,0]  "  identifier  “symbol  table”  entry 

T(as_exp)  +  T(a8_type_range)  +  T'(as_membersliip_op) 


name  a 


package_decl 


2 


2 

param_asaoc_a 

n 

param.a 

i 

n 

parenthesised 

1 

pragma  I  2 


procedure_call 


qualified 

raise 


range 


2 


record 

n 

3 

rename 

1 

return 

1 

reverse 

2 

select 

2 

select_clause 

2 

n 

2)  T(asjiat(i)) 
i=l 

T(as_choice_e)  +  T(as_exp) 

T(aa_stm) 

[0,0]  -  identifier  “symbol  table”  entry 

[0,0]  -  eeneric  subprogram  formal  option 

P(not  in) 

[0,0] 

[0,0] 

P(nuU) 

[0,0]  --  static  numeric  constant 

[0,0]  --  identifier  “symbol  table”  entry 

if  sm_value  s  SMALL_VAL  then  P(small_num_literal_access) 
else  P(num_literal_acce8s)  --  where  num  is  int,  float  or  fixed 

P(or_else) 

[0,0]  --  cannot  have  default  parameters 

[0,0]  —  identifier  “symbol  table”  entry 

save  id(a3_id  &  ‘“body”)  =  P(package_elaboration)  +  T(as  block_stub) 

save  id(as_id)  =  T(a8_package_def)  +  P(package_elaboration) 

--  if  aa_package_def  is  rename  or  instantiation  then  use  other  values 

[0,0]  —  identifier  “symbol  table”  entry 

T(as_decl_sl)  +  T(as_decl_s2) 

n 

2^T(aa_li8t{i])  -  actual  parameter  liata 

n 

2j^T(as_list[i]) 

T(as_exp) 

[0,0]  ••  compiler  directive  may  change  global  params,  but  no  code  gen 
Timing  Assertion  pragmas  are  handled,  of  course. 

[0,0] "  identifier  “symbol  table”  entry 

[0,0]  “  compiler  directive  may  change  global  params,  but  no  code  gen 

[0,0] 

[0,0] "  identifier  “symbol  table”  entry 

[0,0]  ”  identifier  “symbol  table”  entry 

T(as_param_s) 

T(sm_normalized_param_s)  +  P(procedure_call)  +  Insert(a8_name) 

+  P(procedure_end) 

-  sm_normalized  param_s  includes  default  params 

T(as_exp)  --  as.  name  only  used  by  compiler 

Abort  -  exceptions  are  treated  as  errors  at  this  point  and  are  not 
candidates  for  a  min  or  max  path. 

T(as_expl)  +  T(as_exp2) 

n 

y  T(as  list[i]) 
i=l 

[0,0]  -  representation  clause  affects  compilation  only 

T(as_exp_void)  +  Store! function_caU)  +  Stop 

T(a8_dscrt_range ) 

Pfselect) 

1  a8_8elect_clauses_s  1 

+  2  T(as_select_clauBe8_8.a8_U8t[i].as_exp_void)  -  comp  guards 

i=l 

+  {mapCXx.Nodel  +  T(x.as_stm_s)  +  Node2  ,  as_select_clauses_s.a8_list) 
and  if  1  as  stm  s  1  >  0  then  Nodel  +  T(as_stm_s)  +  Node2} 

-  subsumed  in  schema  for  select  node 
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8elect_clauae_s 

n 

~  subsumed  in  schema  for  select  node 

selected 

2 

if  a8_name.8m_obj_type  is  a  record  then 
if  it  has  a  variant  then 

T(aa_name)  +  P(variant_tag_check)  +  T(a8_de8ignator_char) 
else 

T(as_name)  +  T(as_de8ignator_char); 
else  -  it  is  an  expanded  name 

T(a8_name)  +  T(a8_de8igmator_char); 

8imple_rep 

2 

[0,0] "  representation  clause  affects  compilation  only 

slice 

2 

stm_s 

■ 

n 

TXas.listti]) 

i=l 

strmK_bteral 

0 

[0,01; 

stub 

0 

[0,0]  -  Used  for  separate  compilation  purposes  only 

3 

save  id(as_desienator)  =  T(a8_block_8tub)  +  T(a3_header) 

subprogram_decl 

H 

if  aa_8ubprogram_def  *  void 

then  save  id(a8_desiKnator)  =  T(as_8ubproKram_def)  +  T(a3_header) 

subtype 

2 

T(aa_con8  trained) 

subtypejd 

0 

[0,0]  —  identifier  “symbol  table”  entry 

subunit 

2 

save  id(a8_name)  =  T(as_8ubunit_body) 

task.bodv 

2 

P(ta8k_body_elab)  +  {save  id(a8_id  &  ““body”)  =  T(as_block_8tub)} 

ta8k_body_id 

0 

[0,0]  -  identifier  “symbol  table”  entry 

2 

P(ta8k_8pec_elab)  +  {save  id(as_id)  =  T(as_task_def)}  + 
Queue_Activate(a8_id) 

task.spec 

1 

T(a8_decl_8) 

--  Activated  by  allocators  or  declarations  (if  declaration,  queue  activate  it) 

terminate 

0 

P(  terminate) 

timed_entiy 

2 

P(timed_entiy)  + 

Nodel  +  T(aa_8tm_82)  +  Node2;  ••  first  stm  is  a  delay  stm 

Nodel  +  T(as_8tm_sl)  +  Node2;  ••  first  stm  is  entry_call 

type 

3 

T(a8_lype_8pec)  +  T(a8_dscrmt_var_s) 

-  if  task  tyi^  need  to  save  it  as  well 

typejd 

0 

[0,0]  ”  identifier  “symbol  table”  entry 

universal flxed 

0 

0 

0 

[0,0]; 

use 

n 

[0,0]  "  controls  visibility  of  ids;  no  code  generated 

used bltn id 

0 

[0,0] 

0 

[0,0] 

1  used.char 

0 

[0,0]; 

0 

[0,0] 

used_obiect_id 

0 

[0,0]; 

U8ed_op 

0 

[0,0] 

var 

3 

1  id_8 1  •  [T(as_type_8pec)  +  T(a8_object_def)  + 

if  as_object_def  =  void  then  init(as_name)  else  store(a3_name)  + 
if  a8_type_spec  =  ta8k_spec  then  Queue_Activate(a8_id)] 

-  similarly  for  components  of  a8_typie_sp)ec... 

var_id 

0 

[0,0]  —  identifier  “symbol  table”  entry 

variant 

2 

T(as_choice_8)  +  T(as_record) 

2 

T(a8_variant..8) 

variant_s 

n 

n 

T(asji8t{i]) 

void 

0 

[0,0]  —  void  attribute;  no  code  or  semantic  value 

while 

1 

T(a8_exp) 

with 

n 

[0,0]  -  controls  visibflity  of  ids;  no  code  generated 

Figure  4:  Timing  Schema  for  DIANA  Nodes  by  Node  Type 
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Notes: 


-  Schema  with  nodes  are  also  described  graphically  in  the  next 
section. 

-  Expressions  may  be  static.  In  this  case  they  are  evaluated  during 
compilation  and  a  value  for  the  attribute  sm_value  is  added  in  the 
DIANA  representation.  In  this  case  the  expression  is  handled  as  a 
constant  object  of  the  appropriate  type.  In  other  words,  all  nodes 
which  can  be  expressions  are  first  checked  for  the  existence  of  an 
sm_value  attribute  before  proceeding  with  application  of  the  normal 
schema.  These  nodes  include  conversion,  qualified,  parenthesized, 
aggregate,  binary,  membership,  indexed,  slice,  selected,  all, 
attribute,  attribute_call,  and  f^ction_call. 

-  In  loops  the  phrase  n  *  T(x)  is  equivalent  to  unrolHng  the  loop.  This 
is  only  significant  in  cases  where  T(x)  introduces  nodes.  If  T(x)  is 
simply  ad^ditional  edge  weight,  then  n*T(x)  can  be  directly 
computed  using  multiplication. 

-  Similarly,  branching  statements  like  if  and  case  must  be 
graphically  represented  if  they  contain  nodes.  This  is  illustrated  in 
the  next  section. 

-  The  abort  statement  non-cooperatively  cuts  off  a  task  from  further 
rendezvous  and  "marks”  it  for  termination.  This  is  normally  used 
to  recover  from  an  error  state.  In  any  case,  analysis  stops  on 
encoimtering  an  abort  statement  (like  it  does  on  raise  statements) 
and  chooses  another  parallel  path  as  the  worst  or  best  case. 

-  Some  schema  of  the  form  [0,0]  are  actually  unreachable  in 
computing  the  schema  formula  as  defined.  In  general  these  are  “ID 
nodes”  which  represent  an  identifier  or  operator  of  some  sort. 

These  nodes  are  very  important  in  the  computation  of  the  auxihary 
functions  like  store,  access  and  init.  ID  nodes  contain  the  semantic 
type  information  these  auxiliary  functions  need.  ID  nodes  are 
always  leaves  (i.e.,  they  are  never  internal  nodes)  and  are 
meaningful  only  within  the  context  they  appear.  Therefore,  the 
schema  of  their  parent  node  normally  include  any  primitives  that 
context  may  induce  as  well  as  generating  any  auxiliary  function 
computations  necessary. 


Event  Structure  for  DIANA  Objects 


The  potential  context  switches,  or  events,  are  introduced  by  certain  Ada 
program  constructs.  The  corresponding  DIANA  node  types  are  listed  below 
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with  a  graphic  description  of  the  transformation  involved.  Figure  7  in  the 
next  chapter  illustrates  the  transformation  with  some  examples.  ^0^ 
represents  a  vertex  where  a  context  switch  may  occur.  Other  vertices  are 
used  to  connect  edges  and  to  gather  alternative  choices.  Loops  containing  the 
following  structures  are  unrolled  completely  if  bounded  and  as  far  as 
necessary  if  unbounded. 


Ta8k_Body 
Enclosing  Block 


Accept 

Entry_Call 

Delay 

Cond_Entry 


P(dctiv)  +  TCqs_itetn_sV^^  T(qs  stm  s)  +  P(tepminate). 


O 


TC<is.item_s) 


T(as_stm_s 


Task  Activotions 
from  declarative 
block 


PCaccept) 


o 


(rendezvous)  +  T(as_stm_s 


ENTRY.NAME 


P(queue.entry) 

*TCsm.normal  ized^PQram^$') 


o 


ENTRY.NAME 


a 


[0.0] 


[0.0] 


T(as.exp)<y'~^  DelayCdelay  +  PCdelay.cap)) 


[0.0] 


Timed_Entry 


TCentry.call)  +  TCos.stm.sl) 


Select 


<  •*  >  +  T(as_stm,sl) 


<  *♦  >  •  T(occcpt),  TCdelay),  T(terminate) 

or,  for  branch  n,  delayCe)  “  else  branch. 
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TCas_stm_sl , 

If  or  Case 
containing  one  of 
the  above 

branch  1  through  n~l  hove  scjme  sort  of  node  structure,  branch  n  is 
computed  from  all  of  the  sequential  branches  as  is  normally  done. 

If  no  branch  is  purely  sequential,  all  n  branches  hove  nodes. 

In  combining  the  timing  graphs  into  a  system  network,  entry_calls  and 
accepts  are  stitched  together  like  shown  in  the  diagram  below.  Constructs 
which  have  alternative  edges  are  instantiated  with  exactly  one  of  those  edges. 
Where  the  choice  matters,  careful  selection  must  be  made  based  on  the 
analysis  being  performed.  For  instance,  the  worst  case  for  a  cond_entry  in  an 
unbounded  loop  is  to  always  choose  the  else  part.  This  results  in  an  infinite 
chain  of  else's.  (This  also  illustrates  why  it  is  generally  bad  programming 
practice  to  use  a  conditional  entry  in  an  unbounded  loop).  Most  of  the  time, 
however,  the  choices  are  evident. 


Assertions 


An  assertion  is  simply  a  statement.  Classically,  a  software  developer  uses 
assertions  to  make  claims  about  the  state  or  nature  of  the  program  at  a 
particular  point  in  the  code.  Often  these  assertions  are  embedded  as 
comments  in  the  code  itself.  A  small  number  of  programming  languages  like 
Eiffel  include  certain  assertions  as  part  of  their  syntax  [21].  In  some  cases. 
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an  automated  tool  may  process  these  assertions  to  generate  more  powerful 
claims.  This  basic  idea  is  applicable  to  timing  analysis.  In  fact,  it  grants 
much  of  the  power  for  analyzing  designs  or  incomplete  code  segments. 
Assertions  may  be  used  to  bound  unbounded  loops  or  recursion,  to  specify  the 
length  of  time  some  code  will  take  without  specifying  the  code  itself,  and  to 
mark  relevant  points  in  the  analysis. 

A  few  existing  timing  analysis  techniques  use  assertions  of  some  sort. 

Flex  [22],  like  Eiffel,  is  a  program  with  built-in  assertions.  As  a  real-time 
language,  these  assertions  allow  run-time  checking  of  timing  behavior.  The 
Flex  approach  is  part  of  the  language  definition,  however,  and  this  does  not 
help  with  the  analysis  of  Ada. 

Ada  provides  a  handy  construct  for  implementing  assertions,  as  well. 

They  are  not  checked  at  run-time,  however.  The  pragma  statement  does  not 
generate  code  per  se.  Instead  it  passes  a  directive  or  a  suggestion  to  the 
compiler  on  how  to  compile  the  code  around  it.  Except  for  some  standard 
pragmas,  pragmas  are  considered  to  be  implementation  defined.  Since  they 
may  only  change  the  way  code  is  compiled  and  not  its  correctness,  a  compiler 
must  ignore  any  pragma  it  does  not  recognize  (although  it  may  print  a 
warning)  [23]. 

The  seven  assertions  defined  for  this  timing  analysis  are  therefore 
implemented  as  pragmas.  Each  is  prefixed  with  “TA_”  to  help  ensure  no 
conflict  with  any  compiler’s  own  pragma  set.  Pragma  statements  are  very 
similar  to  procedure  calls.  Like  procedure  calls,  arguments  to  the  pragma 
may  be  positionally  associated  or  name  associated.  Either  style  may  be  used 
except  with  the  TA_Time_By_Primitives  assertion  which  must  be  name 
associated. 
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TA_Loop_Bound 

(Low,  High  ;  natural) 


TA_Recursion_Bound 

(Low,  High  :  natural) 


TA  Measure  Start 


TA_Measure_Stop 


TA_Time_Absolute 

(Low,  High  :  Natural) 


TA_Tiine_Mix 

( Instruction_Nuiiiber  ;  Natural; 
Mix  ;  Mix_Type) 


TA_Tinie_By_Priinitive3 

( <prini_naine>  =>  Natural,  _) 


This  assertion  may  appear  as  the  first 
statement  in  a  loop  body.  If  it  does,  it 
defines  the  range  of  times  that  the  loop 
will  execute.  It  overrides  the  bounds 
derived  by  analysis  of  a  for-loop 
specification. 

Similar  to  a  loop  bound.  It  may  occur 
as  the  statement  immediately  following 
a  self-recursive  procedure  or  function 
call.  Mutual  recursion  and  recursive 
call  chains  are  not  supported. 

Ignore  previous  code  in  this  compilation 
unit  for  timing  analysis  purposes.  Use 
this  point  as  an  analysis  start  point. 
This  assertion  is  intended  for  use  in 
main  programs. 

Ignore  following  code  in  this 
compilation  unit  for  timing  analysis 
purposes.  This  assertion  is  intended  to 
mark  where  the  end  event  should  be 
inserted. 

This  assertion  is  treated  exactly  like  a 
code  sequence  which  reduces  to  an  edge 
with  time  bounds  [low,  high]  (in  cycles). 

This  assertion  is  similar  to 
TA_Time_Absolute  but  uses  an 
instruction  count  and  average 
instruction  time  range  (mix)  to  compute 
the  time  bounds. 

Like  TA_Time_Mix,  this  assertion  takes 
instruction  counts  as  its  arguments. 
Instead  of  counting  “average” 
instructions:  however,  the  developer 
can  specify  t  aumber  of  primitive 

times.  Since  named  association  is  used, 
only  the  primitives  of  interest  need  be 
listed. 
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Compiler  Analysis 

In  order  to  determine  the  values  of  primitive  times,  careful  analyses  of  the 
compiler  and  the  target  hardware  architecture  are  required.  The  compiler 
analysis  must  determine  the  code  generated  corresponding  to  each  primitive. 
The  hardware  architecture  analysis  must  calculate  the  execution  time  of  this 
code.  Vendor  input  greatly  simplifies  the  process.  However,  direct 
observation  of  the  compiler  and  hardware  may  be  needed. 

The  implementation  done  in  conjunction  with  this  thesis  uses  the 
Meridian®  Macintosh  Ada  compiler  operating  on  a  Macintosh  Ilsi.  Neither 
the  compiler  nor  the  hardware  were  developed  with  real-time  criteria  in 
mind.  This  means  that  predictability  is  not  directly  supported  and  that 
worst-case  times  may  be  significantly  worse  than  average  case  times. 

Hardware  analysis  must  consider  the  instruction  timing  of  the  processor 
along  with  system  interrupt  handlers  and  bus/processor  contention  for  other 
system  maintenance  activities.  Vendor  timing  data  is  crucial  for  instruction 
timing.  In  the  case  of  the  Macintosh,  its  Motorola  68030  processor  is 
described  in  [24].  Without  timing  data,  extensive  testing  with  logic  analyzers 
would  be  necessary  to  measure  either  instruction  timing  or  primitive  routine 
timing.  These  tests  could  not  guarantee  bounds  on  these  times  imless  they 
can  guarantee  testing  all  possible  conditions  for  execution.  Adequate  vendor 
data  utilizes  design  knowledge  to  ensure  that  time  bounds  given  are  true 
boimds  or  at  least  bounds  under  specified  conditions.  The  Motorola  data 
specifies  the  worst  case  execution  time  under  assumptions  on  the  length  of 


®  Meridian  Ada™  4. 1,  Meridian  Software  Systems  Inc.,  10  Paseur  St.,  Irvine,  CA,  92718. 
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bus  cycles  and  averaging  instruction  alignment  cases.  It  does  not,  however, 
specify  best  case  execution  time. 

Code  generation  analysis  is  also  simplified  with  access  to  vendor  design 
data.  Particularly,  a  compiler  which  uses  DIANA  as  an  intermediate 
representation  is  relatively  easy  to  trace  through  the  code  generation  phase 
relative  to  the  schema.  The  Meridian  compiler,  however,  does  not  use  DIANA 
and  does  not  supply  insight  on  code  generation.  Under  these  circumstances, 
analysis  may  be  accomplished  by  disassembly  of  the  compiler  libraries  and 
test  programs.  These  test  program  listings  are  compared  to  the  source  listing 
and  corresponding  DIANA  structure  to  associate  primitives  with  measurable 
code  segments.  While  this  approach  lacks  the  same  fimdamental  guarantees 
as  hardware  testing,  compiler  activity  is  very  likely  to  follow  the  constraints 
of  the  language  definition  and  common  compilation  practice.  Some  of  these 
constraints  are  embedded  in  the  DIANA  construction.  This  helps  make  the 
relevant  cases  more  obvious.  In  the  event  of  a  prediction  anomaly,  however,  a 
new  set  of  code  generation  circumstances  is  one  of  the  first  things  to  look  for. 
The  primitive  times  used  in  this  implementation  are  developed  using  the 
disassembly  method  described  here. 

Primitive  times  disassociate  the  uniqueness  of  each  compiler/hardware 
/system  grouping,  but  require  analysis  of  each  grouping  to  determine  the 
values  of  these  primitives.  Vendor  data  greatly  simplifies  the  analysis.  A 
production  system  would  need  high  quality,  high  reliability  predictions. 
Vendor  data  is  a  fundamental  necessity  to  achieve  that  level.  In  the 
experimental  implementation  developed  with  this  thesis,  vendor  data  is 
available  on  the  instruction  set  timing,  but  experimentation  is  used  to 
determine  system  interference  and  code  generation  patterns. 
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Execution  Time  Prediction  Algorithm 

Generate  the  timing  graph  as  described  earlier.  Choose  start  events 
(nodes)  of  interest.  Select  the  end  event  of  interest.  Sum  all  edges  which 
“precede”  the  end  event  in  the  graph.  An  edge  “follows”  an  event  when  no 
path  can  be  found  beginning  with  a  start  event  and  not  including  the  event. 
An  edge  that  does  not  follow  an  event,  precedes  it. 

Note  that  without  priorities,  imbounded  loops  containing  conditional 
entries  and  select  statements  with  else  clauses  create  busy  tasks. 
Theoretically,  these  tasks  may  rim  indefinitely  without  relinquishing  the 
processor.  Graphically,  unrolling  these  loops  create  an  indefinite  number  of 
edges  that  have  no  dependencies  on  other  paths  (like  a  rendezvous  does). 
Thus,  if  the  first  of  these  edges  precedes  the  end  event,  then  the  entire 
unrolled  loop  can  precede  the  end  loop.  Thus,  these  constructs  must  be  used 
carefully,  or  else,  a  method  other  than  the  simple  graph  analysis  above  must 
be  used  (such  as  the  CRSM  approach  defined  in  the  next  chapter). 

Discussion 

If  done  by  hand,  applying  this  graph  construction  technique  is  tedious.  It 
needs  to  be  automated.  Non-trivial  problems  generate  extremely  large 
DIANA  trees.  Automating  this  turned  out  to  be  a  difficult  problem,  however. 
The  difficulties  were  not  in  the  technique;  but  instead,  in  the  development 
environment.  The  task  was  larger  than  the  system  could  handle. 

On  the  other  hand,  this  drove  home  the  need  for  an  automated  timing 
analysis  technique.  Being  forced  to  use  this,  relatively  abstract,  method  by 
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hand  made  me  realize  the  extreme  difficulty  in  evaluating  the  timing 
characteristics  of  the  program.  It  also  seemed  to  show  why  timing  analysis  is 
not  done  as  often  as  it  should. 

The  other  issue  with  developing  this  approach  is  the  need  for  compilers 
and  systems  which  make  some  effort  to  be  predictable.  The  Meridian  system 
used  unbounded  recursion  or  iteration  in  several  areas.  Unless  it  was  clear 
that  some  natural  bound  applied  to  the  value,  this  created  great  difficulty. 
Alarms,  in  particular,  used  several  cases  of  recursion  and  endless  loops  — 
mostly  in  searching  and  deleting.  For  this  reason,  they  could  not  be 
adequately  characterized  so  I  deferred  investigating  things  like 
timed_entries. 

The  combination  of  assertions,  source  code  analysis  and  the  concurrency 
analysis  upcoming,  provides  a  broad  toolkit  to  the  programmer/analyst  who 
needs  to  track,  verify,  or  bound  the  performance  of  his  or  her  system. 


Chapter  IV 


Concurrency  Model 


Introduction 

The  amount  of  concvirrency  (both  real  and  perceived)  completely  changes 
the  timing  behavior  from  one  concurrency  model  to  the  next.  Two  common 
models  are  the  fully  concurrent  model  and  the  interleaved  model.  The 
applicable  model  is  closely  tied  to  system  scheduling  decisions  as  discussed 
earlier.  Ada  does  not  specifically  require  some  degree  of  concurrency  or 
another.  Its  model  is  compatible  with  either  a  fully  concurrent  architecture 
or  an  interleaved  system,  as  well  as  combinations  of  the  two. 

This  thesis  applies  to  the  simple  case  of  interleaved  concurrency  on  a 
single  processor.  Currently,  most  Ada  compilers  are  limited  to  direct 
exploitation  of  a  single  processor  using  the  Ada  language  constructs. 

Multiple  processors  are  sometimes  made  available  through  usage  of 
underlying  operating  system  capabilities.  Besides  wishing  to  avoid 
incorporating  arbitrary  operating  system  characteristics,  multiple  processors 
introduce  interprocessor  communication  contention  which  greatly  complicates 
timing  analysis.  Some  on-going  research  is  directed  at  the  topic  of 
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predictable  interprocessor  scheduling  and  communication  [9,  25-27]. 
Certainly,  the  trend  is  toward  multiprocessor  systems  and  direct  Ada  support 
of  these  systems.  Extending  the  approach  here  to  support  multiprocessors 
and  resource  contention  is  the  logical  next  step  in  research. 

This  chapter  discusses  Ada’s  rules  on  concurrency  as  well  as  techniques 
for  modelling  Ada  concurrency.  The  two  techniques  presented  are  a  simple 
PERT  technique  and  Shaw’s  Communicating  Real-Time  State  Machines 
(CRSM)  [8],  The  PERT  technique  is  the  one  developed  in  the  current  schema 
definitions.  It  is  usable  in  single-processor  systems  with  no  task  priorities. 
CRSM  accounts  for  prioritization  and  may  be  extendable  to  multiprocessing 
systems.  It  is  more  complex  to  generate  and  requires  automated  support  to 
execute,  however.  This  chapter  also  outlines  an  approach  for  incorporating 
CRSM  into  the  schema  developed  here. 

Ada  Concurrency  Model 

The  Ada  Concurrency  Model  is  straightforward.  It  follows  closely  Hoare’s 
Communicating  Sequential  Processes  [28,  29].  Tasks  embody  control  flows 
that  may  execute  in  parallel.  The  Ada  main  program  may  be  considered  as  a 
task  for  this  purpose.  At  no  time  may  a  task  with  a  lower  priority  run  if  a 
task  with  a  higher  priority  is  nmable  on  a  given  processor.  Scheduling 
decisions  between  tasks  of  the  same  priority  is  left  implementation 
dependent. 

This  model  implies  that  a  context  switch  between  tasks  will  only  occur 
when  a  task  blocks  or  a  higher  or  equal  priority  task  becomes  runable.  A 
task  may  block  at  any  of  its  synchronization  points.  These  include  the  end  of 
its  activation,  the  activation  point  of  another  task,  an  entry  call,  the  start  or 
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the  end  of  an  accept  statement,  a  select  statement,  a  delay  statement,  an 
exception  handler,  or  an  abort  statement.  It  may  also  block  if  it  uses  a 
blocking  system  call.®  In  the  worst  case,  a  task  blocks  in  all  of  these 
situations  and  a  context  switch  occurs.  A  task  may  become  runable  as  a 
result  of  an  interrupt  or  expiration  of  a  delay  statement.  Again,  the  worst 
case  is  that  each  of  these  results  in  a  context  switch. 

For  the  purposes  of  this  thesis,  the  model  is  simplified.  Exception 
handlers  and  abort  statements  are  ignored  as  error  control  statements. 

While  performance  under  error  conditions  may  also  be  critical  to  real-time 
behavior,  the  additional  complexity  which  exception  handling  and  aborts 
introduce  requires  further  work.  Furthermore,  blocking  system  calls  are  not 
supported  since  their  behavior  is  implementation  dependent.  A  more  general 
implementation  which  accounts  for  resource  contention  could  add  this 
capability.  Finally,  interrupts  are  modelled  as  one  class  of  starting  events; 
that  is,  as  user  specified  nodes  in  the  timing  graph.  The  time  (or  relative 
time)  of  a  series  of  interrupts  must  be  supplied  and  the  proper  entries  graph 
chosen  by  the  user.  Interrupts  may  also  be  handled  solely  by  the  operating 
system  (i.e.,  clock  tick  interrupts).  In  this  case  the  interrupts  are  not  handled 
by  the  Ada  program.  They  are  ignored  in  the  timing  analysis  except  as  they 
contribute  to  system  interference. 

PERT  Networks 

PERT  networks  are  analyzed  by  computing  the  critical  path  to  reach  an 
end  event.  Parallel  tasks  are  allowed  to  execute  in  parallel.  That  is,  PERT 
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In  some  implementations  a  blocking  system  call  will  block  the  entire  Ada  program.  Tliis 
is  quite  common  behavior  in  Unix  where  Ada  tasks  execute  as  light-weight  processes 
within  a  Unix  process.  A  system  call  blocks  the  entire  Unix  process. 
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models  full  parallelism.  Resource  levelling  is  added  to  PERT  analysis  to  force 
it  not  to  schedule  more  parallel  activities  than  resources  allow.  By  specifying 
that  all  events  use  the  same  resoxmce  (CPU)  and  that  there  is  only  one,  the 
PERT  analysis  begins  to  model  an  interleaved  system. 

The  graph  supplied  for  PERT  analysis  is  simply  the  timing  graph  with  the 
following  modifications.  A  dummy  edge  (of  zero  duration)  is  added  between 
all  dangling  activities  and  the  end  event.  This  forces  the  worst  case  situation 
that  all  events  which  may  possibly  precede  the  end  event  will  do  so.  Start 
events  must  be  supplied  a  time  of  occurrence.  The  worst  case  execution  time 
is  then  the  computed  completion  time  for  the  end  event  in  whatever  time 
reference  was  used  for  specifying  the  start  events.  The  number  of  context 
switching  nodes  must  be  counted  and  multiplied  by  the  worst-case  context 
switch  time.  This  quantity  is  added  to  the  computed  end  event  time. 

This  model  is  limited,  however.  For  instance,  PERT  cannot  handle  OR- 
branching,,  OR-branching  is  when  only  one  graph  edge  leaving  a  node  is 
executed  in  a  given  instance.  This  occurs  in  select  and  expanded  "if  or"  case 
statements.  With  select  statements,  the  choice  is  driven  by  the  existence  of 
an  entry  call  (or  the  lack  of  any).  This  situation  is  evident  within  the 
structure  of  the  graph.  An  analyst  (or  perhaps  an  automated  means)  can 
instantiate  the  select  statements  necessary. 

There  are  several  nuances  with  writing  rendezvous  code.  Code  can 
introduce  "race"  conditions  when  two  tasks  call  a  third  which  selects  between 
the  two  call  just  once.  Other  difficulties  are  introduced  by  rendezvous  in  a 
"dependent"  context.  An  independent  context  is  where  a  select  statement  can 
be  called  an  indefinite  number  of  times;  or  more  generally,  when  the  code 
executed  by  an  entry  call  is  independent  of  any  entry  calls  by  other  tasks.  If 
the  dependencies  in  the  rendezvous  sequence  are  deterministic,  then  an 
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analyst  may  construct  the  graph  in  that  sequence.  When  a  choice  must  be 
made  in  selecting  the  caller  of  particular  entry,  it  may  not  be  evident  which 
choice  results  in  the  best  or  worst  time  bound.  Some  choices  may  not 
terminate.  In  the  dependent  context  case,  a  choice  may  affect  the  availability 
of  calls  for  other  choices.  In  the  worst  case,  all  combinations  of  rendezvous 
sequences  would  be  tried.  Trying  all  such  combinations  requires  a  number  of 
network  analyses  exponential  to  the  minimum  of  the  number  of  entry  calls 
and  the  number  of  accept  points.  In  almost  all  cases,  programs  which  may 
not  terminate  or  which  deadlock  based  on  race  conditions  or  which  deadlock 
based  on  the  order  of  task  execution  are  erroneous. 


A  simple  tasking  program  illustrates  how  the  PERT  technique  is  used  in 
analyzing  timing  behavior.  The  program  results  in  four  graphs  which  must 
be  constructed  into  a  single  PERT  network.  The  program  is  followed  by  the 
individual  graphs  and  the  resulting  network. 


procedure  TXtn  La 

COUNT_A,  COCIKT_B  t  INTEGER  i=  0; 
RESULTJC  j  INTEGER  «=  6; 

teisk  TASK_A  Is 
end  TASKA; 

task  TASKS  is 
end  TASK_B; 

task  TASK_C  is 

entry  ENTRYA; 
entry  ENTRYB; 
entry  DONE; 
end  TASK_C ; 

task  body  TASK_A  is 
begin 

for  I  in  1  . .  1000  loop 
COUNTA  COUNTA  +  1; 
end  loop; 

TASK_C.ENTRY_A; 

COUNTA  J=  COUNTA  +  COUNTA; 
end  TASK_A; 


task  body  TASK_B  is 
begin 

for  I  in  1  . .  100  loop 

COUNT_B  J-  COUNT_B  +  I; 
end  loop; 

TASK_C.ENTRY_B; 

COUNT_B  »=  COUNT_B  +  COUNTS; 
end  TASK_B; 

task  body  TASK_C  is 
begin 

for  I  in  1  . .  2  loop 
select 

accept  ENTRY_A  do 

RESULT_C  «=  BESULT_C  /  2; 
end  ENTRY_A; 
or 

accept  ENTRy_B  do 

RESULT_C  «=  RESULTjC  +  4; 
end  ENTRYJB; 
end  select; 
end  loop; 
accept  DONE; 
end  TASKC; 

begin  —  DOIT 
TASKJC.DONE; 
end  DOIT; 


Figure  6:  Simple  Tasking  Program 
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Figure  7:  Timing  Graphs  for  Simple  Tasking  Program 


Figxire  8:  PERT  Network  for  Simple  Tasking  Program 
In  figure  8,  the  PERT  network  is  simply  constructed  by  matching  together 
the  timing  graphs  for  the  various  tasks  and  subprograms.  The  boldface  edges 
are  the  ones  added  to  construct  the  network.  In  this  case,  they  are  added  at 
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entry  calls  and  task  activations.  The  triangular  node  represents  the  end 
event.  Zero-weighted  edges  tie  the  completion  of  all  relevant  threads  to  this 
event.  Note  that  the  entry  calls  in  Task  A  and  B  are  independent.  The 
network  could  be  constructed  with  the  accepts  in  Task  C  reversed.  The  same 
edges  and  nodes  would  still  precede  the  end  event;  the  order  does  not  matter. 

Communicating  Real-Time  State  Machines 

Commimicating  Real-Time  State  Machines  (CRSM)  are  an  executable 
specification  technique  [8].  Their  key  feature  is  the  capability  for  describing 
timing  properties.  They  are  described  by  a  system  model  and  operational 
semantics.  Each  concurrent  task  is  represented  by  a  state  machine  with 
synchronous  intertask  communication.  The  following  paragraphs  briefly 
describe  what  is  developed  in  the  above  citation. 

The  system  model  is  a  set  of  state  machines  and  communication  channels . 
The  state  machines  are  described  by  a  set  of  states  and  transitions.  The 
transitions  have  labels  of  the  form  guard  -*  command.  Guards  are  conditions 
that  must  be  satisfied  before  execution  of  the  associated  command.  Omitting 
the  guard  is  equivalent  to  a  guard  of  true.  The  commands  may  change  local 
variables  and/or  communicate  with  other  machines.  Channels  abstractly 
represent  communication  between  two  machines.  They  are  identified  by  an 
event  name.  The  event  may  have  parameters  associated  with  it;  these  are  set 
during  the  communication. 

The  operational  semantics  describe  how  to  transform  an  input  of  CRSM's 
and  their  channels  into  a  time-sequenced  event  trace.  The  basic  approach  is 
to  construct  next  event  lists  for  each  machine.  This  is  followed  by  selecting 
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the  earliest  event(s)  from  the  various  lists.  These  are  executed,  time  up>dated, 
and  the  process  repeated. 

Time  is  represented  as  a  range  [min,  max]  associated  with  each  transition. 
This  is  the  time  it  takes  for  the  transition  to  execute.  Communication  occurs 
instantaneously.  Also  each  machine  has  an  associated  real-time  machine 
which  can  be  used  to  model  delays  as  well  as  get  time  stamps. 

CRSM  and  Ada  Tasking  Structures 

The  basic  mapping  between  Ada  and  CRSM  is  to  model  each  Ada  task 
(and  master  subprogram)  as  a  machine.  Transitions  represent  execution  of 
some  statement  or  sequence  of  statements.  Communication  between  tasks 
(entries)  are  modelled  using  communication  channels.  The  main  change  is 
that  channels  can  have  out  variables  passed  as  actual  parameters.  The  event 
synchronization  does  not  map  exactly  to  an  Ada  rendezvous  which 
synchronizes  the  sender  and  receiver  for  some  bounded  but  significant 
amount  of  time.  Thus,  events  are  used  to  synchronize  both  the  start  and  the 
end  of  the  rendezvous.  Furthermore,  th^  calling  machine  is  not  allowed  any 
other  transitions  between  the  events  starting  and  ending  the  rendezvous. 

Operationally,  the  timing  analysis  technique  models  programs  on  a  single 
processor.  Therefore,  CRSMs  are  executed  as  described,  hut  instead  of 
running  all  machines  in  parallel,  only  one  machine  is  selected  to  run  at  at 
time.  A  trace  begins  with  the  event  of  interest  and  an  arbitrary  runable 
machine  is  selected  to  run  at  each  "blocking"  point.  Because  of  Ada 
interleave  semantics,  the  order  transitions  are  executed  is  not  important  (for 
independent  calling  contexts).  Priorities  can  be  introduced  by  making 
scheduling  decisions  based  on  the  Ada  priority  scheme. 
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Because  CRSM  and  Ada  both  have  roots  in  Hoare’s  CSP,  it  is  not 
surprising  that  the  mapping  between  them  is  straightforward.  By 
reintroducing  parallelism  to  the  operational  semantics,  CRSM  can  simulate 
multi-processing  of  Ada  programs.  This  and  the  ability  to  make  scheduling 
decisions  give  CRSM  a  great  deal  more  power  than  a  simple  PERT 
representation  of  the  program. 

Integrating  Schema  Analysis  and  CRSM  Construction 


Constructing  timing  models  using  CRSM  is  not  much  different  than  using 
PERT.  Both  techniques  use  graphs.  The  difference  is  in  the  forms  of  the 
graph;  and,  of  course,  what  they  mean  and  how  they  are  analyzed.  Thus,  the 
same  schema  apply  except  for  some  of  those  which  construct  graph  elements. 
These  schema  are  replaced  by  the  constructs  in  the  following  table.  Input 
events  are  marked  with  question  marks.  These  correspond  to  output  events 
with  the  same  name  and  marked  with  exclamation  points.  The  input  RT?[x] 
is  an  input  from  the  real-time  machine  associated  with  the  task  to  occur  at 
least  X  seconds  in  the  future. 


Task_Body 


P(activ)  + 


Enclosing  Block 


Accept 


Entry_Call 


Delay 

Cond_Entry 

Tuned_Entry 

Select 

For  the  worst  case  analysis,  the  max  time  is  used  for  each  transition.  For 
the  best  case  analysis,  the  min  time  is  used.  The  completion  of  the  analysis 
occurs  when  the  activities  triggered  by  the  starting  events  subside.  Note  that 
this  model  does  not  require  assembly  of  the  generated  timing  graphs.  They 
are  input  to  the  operational  CRSM  model  as  is. 

Dependent  tasking  contexts  introduce  similar  problems  in  this  model 
since  the  calling  order  may  change  based  on  the  length  of  execution  at  some 
point.  This  change  in  calling  order  may  result  in  an  overall  faster  or  slower 
time.  Thus,  always  choosing  the  max  or  min  time  may  not  generate  the  worst 
or  best  case  respectively. 

Discussion 

The  concurrent  constructs  of  Ada  require  special  consideration  for  timing 
analysis.  On  a  single  processor,  only  one  task  can  use  the  processor  at  a  time. 
This  interleaved  model  means  that  the  execution  time  of  a  program  is  the 
sum  of  the  time  spent  in  each  task  with  one  exception.  If  any  tasks  use 
delays,  then  it  may  be  possible  that  no  task  is  runable  at  some  point.  This 


PCdelay)  + 


T(<**>)  ^  T(as_stm_sn) 

<**>  ..  accept,  delay,  terminate  or  else 
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idle  time  must  also  be  added  to  the  program  execution  time.  PERT  analysis 
can  help  make  this  determination. 

CRSM  provides  a  more  powerful  model.  Although  developed  as  a 
specification  method,  it  serves  well  as  a  descriptive  technique.  It  can  model 
multiple  processors  as  well  as  more  complex  scheduling  decisions.  Its 
drawback  is  the  requirement  for  a  specific  tool  to  nm  the  model. 

Dependent  tasking  contexts  are  system  designs  where  the  timing 
properties  are  dependent  on  the  order  that  entry  calls  occur.  Neither  PERT 
nor  CRSM  can  simply  determine  the  bounded  execution  time  of  such 
programs.  Trying  all  possible  orders  of  entry  calls  is  the  sure  way  of  finding 
the  bounded  execution  time;  however,  this  is  an  exponential  growth 
approach.  Further  understanding  and  characterizing  the  conditions  which 
cause  dependent  tasking  contexts  is  necessary  to  determine  if  a  better 
approach  can  be  developed  or  if  the  class  of  programs  can  be  ruled  out. 


Chapter  V 


Experiments 


Introduction 

Experiments  consist  of  benchmark  tests.  These  tests  are  compiled  and 
run  in  a  dedicated  system  environment.  They  are  also  converted  to  a  DIANA 
representation  which  is  fed  to  an  automating  timing  graph  generator.  The 
resulting  timing  graphs  are  combined  into  a  network  and  analyzed  by  hand. 
The  results  are  adjusted  for  system  interference  are  compared  to  the 
experimentally  observed  times.  In  a  few  cases,  both  the  results  and 
experimental  times  are  compared  to  worst  case  times  computed  using  hand 
analysis  techniques  like  Knuth’s. 

Setup  of  the  Experiments 

As  stated  in  the  introduction,  the  experiments  consist  of  Ada  programs 
which  imdergo  timing  analysis,  which  are  timed  while  executed,  and  whose 
prediction  and  execution  results  are  compared.  The  benchmark  programs 
come  from  two  sources.  The  first  is  the  Special  Interest  Group  for  Ada  of  the 
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Association  for  Computing  Machinery  (ACM  SIGAda)  Performance  Issues 
Working  Group  (PIWG).  The  second  are  programs  specifically  constructed  to 
include  a  wider  selection  of  language  features  and  exercise  some  of  the 
capabilities  of  the  analyzer. 

The  PIWG  has  constructed  a  series  of  benchmarks  that  measure  and 
compare  various  features  of  the  Ada  language.  The  benchmarks  measure 
both  compilation  and  execution  performance.  For  these  experiments,  the  best 
choices  are  execution  benchmarks  which  test  basic  sequential  language 
constructs  and  which  test  simple  tasking  situations.  Many  of  these 
benchmarks  are  relatively  simple,  so  their  object  code  modules  may  also  be 
hand  analyzed  for  timing  behavior. 

The  other  set  of  programs  are  somewhat  more  complex,  but  still  relatively 
small  (less  than  100  SLOG),  In  both  cases  the  programs  are  enclosed  within 
an  iteration  loop.  The  computer  clock  is  read  immediately  before  the 
iteration  loop  and  immediately  after  it  completes.  The  iteration  loop  may  be 
run  several  times.  In  the  case  of  the  PIWG  benchmarks,  the  number  of 
iterations  varies  from  one  run  to  the  next. 

Each  program  is  compiled  on  a  Rational  RIOOO.'^  The  Rational  creates  a 
DIANA  tree  for  the  program.  The  DIANA  tree  is  copied  into  a  text  file  and 
transferred  back  to  the  Macintosh.  The  Rational  represents  node  identifiers 
with  a  long  hexadecimal  value;  pointers  in  semantic  attributes  are  marked 
with  a  caret  ('').  These  values  are  replaced  with  a  simple  integer  from  the  set 
1  to  n  where  n  is  the  number  of  nodes  in  the  file.  Semantic  pointers  are 
replaced  with  a  similar  value  with  a  package  id  extension  (e.g.,  ^standard.9). 
If  it  had  been  available,  this  file  would  be  loaded  into  the  timing  analysis 


Rational  and  RIOOO  are  registered  trademarks  of  Rational,  1501  Salado  Drive, 
Mountain  View,  California,  94043 
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program  which  generates  timing  graphs  for  its  various  program  units  (i.e., 
subprograms,  tasks,  package  elaborations).  Note  that  compilation  units  upon 
which  it  depends  must  be  loaded  before  it;  particularly  the  standard  package. 
The  timing  graphs  which  result  are  printed.  Without  the  analysis  program, 
the  timing  graphs  are  generated  by  hand  application  of  the  schema  to  the 
DIANA  representations.  Building  networks  from  these  graphs  and  analyzing 
them  generate  the  boimded  execution  time  predictions  of  interest. 

The  expected  execution  time  is  then  compared  to  actual  executions.  The 
program  is  compiled  and  run  on  the  Macintosh  system.  No  other  application 
programs  are  run  including  system  extensions  like  screen  savers  or  virus 
protection  software.  Furthermore,  keys  are  not  pressed  after  beginning  the 
test  execution  and  the  mouse  is  not  moved.  Other  programs,  particularly 
system  extensions,  and  input  device  activity  all  add  to  system  interference. 
The  programs  do  not  require  disk  or  screen  I/O  within  the  critical  timing 
section.  The  benchmark  programs  complete  by  printing  out  the  timing 
measurements  it  made. 

The  execution  time  of  the  program  (Tex)  is  represented  in  the  equation; 


Tmeasured  -  Tdock  +  Tloop-overhead  +  I  x  Tex 
where  I  is  the  number  of  iterations  in  the  loop.  Solving  this  for  Tex  results  in 

Tex  —  [Tmeasured  "  (Tdock  +  Tloop-overhead)]  /  I  ~  Tmeasured  / 1 
if  I  is  large  enough.  Before  comparison,  the  predicted  times  must  be  adjusted 
for  the  estimated  system  interference  experienced  by  the  test. 

System  interference  is  the  amount  of  time  the  system  spends  handling 
interrupts  rather  than  running  the  program  of  interest.  A  simple  benchmark 
measures  the  amount  of  time  in  a  simple  loop.  Running  this  benchmark 
under  the  system  configuration  described  above  gives  the  data  necessary  to 
derive  a  range  of  nominal  system  interference.  The  benchmark  was 
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disassembled  and  hand  analyzed.  The  result  was  compared  to  the  timed 
execution  result  and  a  range  for  system  interference  determined. 

A  better  experiment  was  attempted.  This  would  measure  the  execution 
time  with  interrupts  disabled  and  compare  it  to  the  normally  measured  time. 
The  relative  difference  would  represent  system  interference.  The  experiment 
failed  because  the  system  routine  for  reading  the  hardware  clock  directly  did 
not  work  and  the  other  clocks  were  interrupt  driven.  Note  that  disabling 
interrupts  for  any  significant  period  of  time,  in  general,  would  break  the  Ada 
run-time  system  and  thus  is  not  feasible  for  application  experiments  . 
However,  until  the  problems  mentioned  above  can  be  fixed,  disabling 
interrupts  is  not  viable  for  characterizing  system  interference,  either. 

’^e  expected  execution  time  of  the  system  interference  benchmark  was 
computed  as  requiring  228,030,018  -  250,035,023  cycles  which  at  25  MHz 
equals  9.12  - 10.00  seconds.  The  measurement  was  repeated  100  times.  Each 
measurement  was  either  14  or  15  seconds.  The  first  time  was  observed  45 
times;  thus  the  weighted  average  is  14.55  seconds.  This  means  the  time 
spent  in  interrupt  handlers  is  4.55  -  5.43  seconds  distributed  across  60  ticks 
per  second.  From  this  data  the  average  time  spent  in  the  tick  interrupt 
handler  is  5.21  -  6.22  ms.  The  nominal  system  interference,  the  percentage  of 
each  tick  spent  handling  interrupts,  is  then  31.3  -  37.3%.®  Thus,  62.7  -  68.7% 
of  the  processor  is  available  for  the  experiment  and  the  predicted  times 
should  be  divided  by  these  amounts  to  give  the  comparable  predictions  with 
system  interference  accounted  for. 


With  five  83^tem  extensions  installed,  the  system  interference  rises  to  60-65%. 
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Experimental  Results 


The  following  table  summarizes  the  results  collected.  All  results  are 
tabulated  in  Appendix  D.  Without  the  automation  to  generate  timing  graphs, 
very  few  predictions  were  completed.  The  predicted  times  are  corrected  for 
system  interference. 
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Table  1:  Iterated  Experiment  Results 


Experiment 

Measured 

Predicted 

Time 

Time 

A000091 

1.10-1.20  ms 

A000092 

2.78  -  2.84  ms 

SimpleTasks 

11.8-14.6 

Table  2:  Sin^e  result  experiments 


Interpretation 


For  the  experiments  completed,  the  predictions  bound  the  measurements 
(as  shown  in  figures  9  and  10).  This  is  hardly  surprising  if  the  primitives  and 
schema  are  defined  and  calculated  correctly.  The  question  is  then  how  good 
the  boimds  are.  The  limiting  condition  on  the  tightness  of  the  bounds  is  the 
tightness  of  the  primitives  involved  in  the  prediction. 
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Experiment  P000001  Control  Loop 
Measured  vs.  Expected 
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Figure  9:  A  Plot  of  Experiment  POOOOOl  Control  Loop  Results  and  Expectations. 

The  upper  bound  of  each  primitive  can  be  expressed  as  the  lower  bound 
multiplied  by  a  factor.  The  lower  bound  prediction  is  the  sum  of  the  primitive 
lower  bounds.  The  upper  bound  prediction  can  be  expressed  as  the  lower 
bound  multiplied  by  a  weighted  average  of  the  primitive  upper  bound  factors. 
The  average  is  weighted  by  the  frequency  of  occurrence  for  a  given  primitive 
in  the  prediction  and  by  the  amount  of  time  represented  by  the  primitive. 

Some  interesting  limits  arise  from  this  view.  Foremost  is  the  observation 
that  the  difference  between  the  actual  program  execution  time  and  the  upper 
bound  must  be  less  than  the  factor  between  the  lower  and  upper  bounds.  In 
the  POOOOOl  experiments  above,  the  factor  between  the  bounds  are  1.35  for 
the  control  loop  and  1.58  for  the  test  loop. 
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Experiment  POOOOOl  Test  Loop 
Measured  vs.  Expected 
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Figure  10;  A  Plot  of  Experiment  POOOOOl  Test  Loop  Results  and  Expectations. 

The  second  observation  is  that  the  factor  for  the  code  in  a  loop  body  is 
invariant,  i.e.,  it  does  not  change  if  the  number  of  loop  iterations  change. 
Plotting  the  upper  and  lower  bounds  against  iterations  of  the  loop  on  log-log 
charts  would  generate  parallel  lines.  This  is  the  case,  in  fact,  for  the  graphs 
above  when  plotted  on  a  log-log  rather  than  semi-log  scale. 

The  final  observation  applies  when  branching  and  variable  loop  bounds 
are  ignored.  The  factor  between  the  bounds  of  the  prediction  cannot  exceed 
the  largest  factor  between  the  bounds  of  any  primitive  used  in  the 
calculation.  This  follows  from  the  way  a  weighted  average  works.  An 
average  cannot  exceed  the  largest  of  its  input  data.  On  the  a^'chitecture 
studied,  many  primitives  only  vary  by  30  -  50%,  others  vary  by  factors  of  four 
or  more.  Tight  primitive  bounds  result  in  tight  prediction  bounds. 
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In  the  experiments  above,  the  worst  case  bound  exceeded  the  worst  case 
measurement  by  factors  of  5.2%  and  33.7%  for  the  control  loop  and  test  loop 
respectively.  However,  testing  may  not  execute  the  worst  case.  With  the  low 
number  of  runs  conducted  so  far  these  numbers,  particularly  the  second,  are 
probably  high.  The  observation  in  the  previous  paragraph,  however, 
indicates  that  the  POOOOOl  code  is  relatively  tight  compared  to  the  primitives 
that  may  be  encountered  in  other  code.  Examples  involving  tasking,  delays, 
or  floating  point  arithmetic  have  much  larger  factors  between  their  bounds. 

Coverage  of  the  execution  results  offer  another  perspective  on  how  good 
the  predicted  bounds  are.  Coverage  is  the  range  of  test  results  from  the 
lowest  time  to  the  highest  time  compared  to  the  range  of  the  bounds.  For 
instance,  the  measurement  runs  for  the  POOOOOl  control  loop  cover  iterated 
8192  times  cover  the  range  41  •  48  seconds.  The  bounds  are  37.4  and  50.5 
seconds.  So,  the  results  cover  seven  seconds  of  the  13.1  seconds  between  the 
boimds  or  53%. 

Without  more  testing  and  study  of  the  implications  of  these  metrics,  it  is 
imprudent  to  draw  any  conclusions.  The  metrics  of  difference  factors  and 
coverage  help  visualize  how  the  predictions  stack  up  to  the  actual  executions. 
Predictions  that  generate  a  factor  of  1  between  worst  case  execution  and  the 
worst  case  bound  and  100%  coverage  are  obviously  ideal.  They  may  be 
unrealistic;  but  may  also,  in  fact,  be  achievable  by  applying  the  technique  to 
systems  with  hardware  and  compilers  developed  to  generate  predictable  code. 


Chapter  VI 


Discussion  and  Future  Research 


The  proposed  approach  to  timing  analysis  is  promising.  It  satisfies  the 
objectives  outlined  in  Chapter  I,  but  can  certainly  be  improved.  Specifically, 
it  does  not  take  advantage  of  all  the  context  information  available  to  it;  it 
does  not  handle  exception  processing  or  I/O;  and  it  is  limited  to  single 
processor  systems.  These  are  all  areas  that  should  be  pursued  further. 
Additionally,  continuing  improvement  can  be  made  to  tighten  the  bounds  by 
tightening  the  primitive  time  bounds  and  manipulating  the  schema  to  fit 
better. 

In  extending  this  approach  it  is  important  to  keep  the  objectives  in  mind. 
A  particularly  difficult  one  is  portability,  the  applicability  of  the  technique  to 
different  hardware  and  compiler  systems.  By  manipulating  the  schema  to  fit 
more  closely  what  a  particular  compiler  does,  the  performance  with  that 
compiler  will  improve.  It  may  be  incompatible,  however,  with  another 
compiler.  Thus,  the  schema  must  continue  to  conform  closely  with  the 
language  definition. 

Park  and  Shaw  has  already  somewhat  considered  the  tradeoff  between 
tightness  of  the  execution  time  bounds  and  portability  [30].  They  look  at 
large  and  small  atomic  blocks  represented  by  their  primitive  times.  This  is 
another  way  of  factoring  context  into  the  picture.  By  defining  primitives  in 
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larger  terms  (such  as  an  entire  assignment  statement),  one  can  better 
characterize  the  compilers  behavior.  The  disadvantage  is  that  many  more 
primitives  are  needed  (a  single  assignment  primitive  is  not  sufficient;  one  will 
be  needed  for  each  m^or  type  and  for  significant  optimization  patterns).  The 
goal  is  to  determine  a  balanced  set  of  primitives  and  the  method  for 
identifying  the  proper  context  for  using  them. 

The  most  difficult  part  of  the  language  and  most  implementations  is  the 
tasking  model  and  constructs.  Better  characterization  and  understanding  of 
tasking  activity  is  a  high  priority.  Here  more  than  any  place  else,  support  by 
the  compiler  vendor  is  crucial  to  understanding  the  system.  Tasking 
implementations  are  10,000’s  of  lines  of  code.  The  exercise  of  characterizing 
the  tasking  behavior  of  the  compiler  may  also  benefit  the  compiler  vendor 
who  should  discover  what  parts  of  the  implementation  are  least  predictable 
and  most  difficult  to  characterize. 

Another  way  to  distinguish  characterizations  is  using  modes  and 
variability.  I  use  these  terms  to  describe  the  things  which  vary  execution 
times  from  one  system  or  instance  to  the  next.  Modes  are  those  things  that 
are  fixed  at  some  point  in  instantiation  of  the  system  (e.g.,  instruction  word 
alignment  in  the  object  code  image).  Variability  refers  to  environmental 
factors  which  may  continue  to  vary  (e.g.,  input  values,  competing  workloads, 
and  operator  controls).  By  so  categorizing  these  things,  further 
characterization  of  the  syst-  ;ai  may  become  available  as  modes  are  fixed  for  a 
particular  instance. 

Modes  and  variability  can  be  modelled  to  some  degree  with  random 
processes  and  variables.  A  more  general  understanding  of  the  system  is 
potentially  available  using  probabilistic  models  like  those  in  [31]  and  [32]. 
Characterizing  primitive  times  as  random  variables  may  allow  further  a 
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priori  characterization  of  a  prediction’s  factors  and  ranges.  An  important 
distinction  that  may  be  provided  by  studying  modes  and  variabihty  is 
separation  of  dependent  and  independent  random  variables.  These  models 
may  allow  for  reasonable  specification  and  verification  of  a  non-perfect 
system,  e.g.,  the  system  that  requires  98%  availability. 

The  trickiest  problem  that  must  be  addressed  is  multi-processing  and 
shared  resources.  Gerber  and  others  have  started  looking  at  timing  analysis 
in  light  of  resom-ce  contention  [33].  Tying  resource  sharing  into  a  general 
abstract  timing  analysis  model  would  provide  a  critical  tool  to  the  developers 
of  real-time  systems. 

I  intend  to  continue  exploring  this  subject  as  my  research  area  at  the  US 
Air  Force  Acad-  iiy.  Based  on  personal  experience  and  the  literature, 
systems  developers  need  timing  analysis  techniques  that  can  apply  to  the 
systems  they’re  building  today  and  will  be  building  tomorrow.  These 
techniques  must  span  the  entire  development  cycle,  be  general  enough  to  use 
on  several  projects,  and  provide  reliable  performance. 
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Appendix  A 


Timing  Primitives  for  Mac  Ilsi  and  Meridian  Ada 

The  following  lists  the  timing  primitives  as  identified  by  analysis  of  the 
Ada  language,  DIANA  representation  and  Meridian  Ada  code  generation. 
Where  a  high  or  low  execution  timing  bound  has  been  determined  for  the 
primitive,  the  value  is  shown  in  cycles.  The  Mac  Ilsi  executes  at  25  MHz. 

accept 
access 

activ  184 

activation 
allocate_main 
and_then 
array_access 
array_aggr_comp_access 
array_aggr_setup 
array_cat 
array_comp_access 
arTay_comp_store 
array_ge 
arTay_greater 
arrayjn 
arrayje 
arrayjesser 
array_not_in 
array^store 
attr_address 
attr_afl 
attr_base 
attr_callable 
attr_constra  ined 


attr_count 
attr_delta 
618  attr_digits 
attr_emax 
attr_epsilon 
attr_first 
attr_first 
attr_first(  N ) 
atfT_first_bit 
attr_fore 
attr_iinage 
attrjarge 
attrjast 
attr_last(N ) 
attr_last_bit 
attrjength 
attr_length(N) 
attr_machine_emax 
attr_machine_einin 
attr_machine_mantissa 
attr_machine_overflows 
attr_machine_radix 
attr_machine_roiinds 
attr_mantissa 
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attr_po8 

attr_position 

attr_pred 

attr_range 

attr_range(N) 

attr_safe_emax 

attr_safe_large 

attr_safe_small 

attr_3ize 

attr_small 

attr_storage_size 

attr_succ 

attr_terniinate(i 

attr_val 

at±r_value 

attr_width 

ba_and 

ba_not 

ba_or 

ba_xor 

bool_acceas 

bool_and 

bool_eq 

bool_neg 

bool_not 

bool_or 

bool_st»re 

booLxor 

cond_entry 

case 

context  switch 

convert_array 

convert_derived 

convert_fixed2float 

convert_fixed2int 

convert_float2fixed 

convert_float2mt 

convert_int2fixed 

convert_int2float 

default_param 

delay 

else 

fixed_abs 

fixed^access 

fixed_div 

fixed_eq 

fixed_ge 
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fixed.^reater 

fixedjdentity 

fixed_in 

fixedje 

fixedjesser 

fixed_miniis 

fixed_mul 

fixed_neq 

fixed_negation 

fixed_not_in 

fixed_plus 

fixed_store 

float_access 

float_ab3 

float_div 

float_eq 

float_exp 

float_identity 

float_in 

float_ininus 

float_mul 

float_neq 

float_negation 

float_not_in 

float_pIu8 

float_store 

for_end 

for_iter 

forjoop 

f\mction_access 

function_call 

function_end 

if 

int_abs 

int_div 

int_eq 

mt_exp 

int _ge 

int_greater 

intjdentity 

int_m 

intje 

intjesser 

mt_literal_access 

int_mmus 

int_inod 

int_neq 


int_negation 

int_not_in 

int_plus 

int_rem 

mt_times 

integer_acces3 

integer_store 

iter 

loop 

loop_end 

nuD 

or_el8e 

package_elaboration 

procedure_call  ® 

procedure_end 

queue_entry 

range_check 

real_literal_acces3 

record 

record_aggr_comp_acce3 

record_aggr_setup 

record_comp_access 

record_comp_store 

rendevous 

select 

slice_acce8s 

3lice_store 

8tring_literal_access 

ta8k_body_elab 

ta8k_spec_elab 

terminate 

timed_entry 

variant_tag_check 


8  12 

4  16 

5  18 


40  858 

28  100 

992  2082 


92  158 

2202  4166 

24  94 
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Worst  case  u.me  is  only  301  when  the 
procedme  contains  no  tasks 


Appendix  B 


Test  Program  Source  Code 


A000001 

with  TEXT_IO  ;  use  TEXT.IO  ; 

package  DURATION_IO  is  new  FIXEO_IO  (  DURATION  )  ; 


A000018 

--  This  is  a  universal  Ada  function  to  get  CPU  time  in  seconds 
--  of  type  DURATION  on  non  time.sharring  systems  where  a 
--  tailored  CPU_TIME_CLOCK  is  not  reasonable 
--  Do  not  cross  a  midnight  boundry 

--  It  is  modified  to  read  the  clock  using  the  Mac  OS  clock  routine  rother 
--  than  the  calendar  package.  This  gives  l/60th  second  rother  than  1  sec 
--  resolution. 

with  EVENTS! 
with  MAC.TYPES; 

function  CPU.TIME.CLOCK  return  DURATION  is 

MaxTicks  :  Constant  ;=  60  *  86400;  --  Durotion’last 
NOW  :  MAC.TYPES. LONGINT  :=  EVENTS .TICKCOUNT  ; 

begin 

return  DURATION  (  FLOAT  (NOW  mod  maxTicks)  /  60.0  )  ; 
end  CPU.TIME.CLOCK  ; 


A000021 

package  REMOTE. GLOBAL  is 
A. ONE  :  INTEGER;  -- 

GLOBAL  :  INTEGER  :=  1  ; 


procedure  REMOTE;  -- 


for  explicit  control  of  optimization 

a  constant  1  that  can  not  be  optimized  awoy 
A.ONE  is  intentionally  visible.  DO  NOT  CHANGE  IT 

global  object  con  not  be  optimized  away 
GLOBAL  is  changed  by  measurement  programs 
the  initializotion  to  1  is  used  in  the  body 
but  could  be  changed  by  elaboration  order 

do  to  calls  to  this  procedure,  no  compiler 
can  optimize  away  the  computotion  an  GLOBAL 


procedure  CHECK.TIME  (  TEST.DURATION  :  in  DURATION  )  ; 

Just  print  message  if  TEST.DURATION  less  then 

100  *  SYSTEM. TICK  or  DURATION ’SMALL 


end  REMOTE.GLOBAL; 
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A000022 

with  SYSTEM,  TEXT.IO  ; 


package  body  REMOTE_GLOBAL  is 
LOCAL  :  INTEGER; 


--  must  be  compiled  last 
for  explicit  control  of  optimization 


procedure  REMOTE  is  --  this  is  an  optimization  control  procedure 
begin 

GLOBAL  :=  GLOBAL  +  LOCAL;  —  be  sure  procedure  is  not  optimized  away 
exception 

when  NUMERIC.ERROR  => 

REMOTE  ;  --  can  not  happen  if  test  is  working  C  prevents  inlining  ) 
end  REMOTE; 


procedure  CHECK_TIME 
begin 

if  TEST.DURATION  < 
TEST_DURATION  < 
TEXT_IO.PUT_LINE 

end  if  ; 

end  CHECK_TIME  ; 


C  TEST_DURATION  :  in  DURATION  )  is 

100  •  DURATION 'SMALL  or 
100  •  SYSTEM. TICK  then 

(  ••  *****  tEST.DURATION  not  large  compared  to 
&  "DURATION 'SMALL  or  SYSTEM. TICK  "  )  ; 


begin 


A_0NE  :=  1  ;  must  not  be  changed  by  measurement  programs 

LOCAL  ;=  GLOBAL  -  A_0NE;  --  really  a  zero  but  compiler  doesn't  know 


end  REMOTE.GLOBAL; 

--  This  is  the  ITERATION_COUNT  control  package  for  feoture  measurements 
--  The  set  of  procedures  provide  the  automatic  stabilizing  of  the 
--  timing  measurement.  The  measurement  CPU  time  must  be  greater  than: 

--  1.0  second,  DURATION 'SMALL  *  100  ,  SYSTEM. TICK  •  100 


--  Note:  If  there  is  no  control  loop,  the  START.CONTROL  and  STOP.CONTROL 
do  not  need  to  be  called. 


package  ITERATION  is  -  A000031.ADA 

subtype  ITERATION.COUNTS  is  INTEGER  range  1  ..  32768; 

procedure  START.CONTROL  ; 

procedure  STOP.CONTROL  (  GLOBAL  :  INTEGER  ; 

CHECK  ;  INTEGER  )  ; 

procedure  START.TEST  ; 

procedure  STOP.TEST  (  GLOBAL  :  INTEGER  ; 

CHECK  :  INTEGER  )  ; 

procedure  FEATURE.TIMES  (  CPU.TIME  :  out  DURATION  ; 

WALL. TIME  :  out  DURATION  )  ; 

procedure  INITIALIZE  (  ITERATION.COUNT  :  out  INTEGER  )  ; 

procedure  TEST.STABLE  (  ITERATION.COUNT  :  in  out  INTEGER  ; 

STABLE  :  out  BOOLEAN  )  ; 


end  ITERATION  ; 
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A000033 

--  Iteration  control  package  body  C  for  test  development  ) 

This  version  is  instrumented  and  may  interefere  with  some 
types  of  tests 

with  CPU _TIME_C LOCK  ;  --  various  choices  on  tope 

with  CALENDAR  ;  --  used  for  WALL  clock  times 
with  SYSTEM  ;  --  used  to  get  value  of  TICK 
with  TEXT_IO  ;  --  only  for  diagnostics 

with  DURATION_IO  ; 

packoge  body  ITERATION  is  --  A000832.ADA 


--  CPU  time  variobles 

CONTROL_TIME_INITIAL  :  DURAHON  ;  —  sampled  from  CPU_TIME_CLOCK  at  beginning 
CONTROL_TIME_FINAL  :  DURATION  ;  --  sampled  from  CPU_TIME_CLOCK  at  end 
CONTROL_DURATION  :  DURATION  ;  —  (FINAL-INITIAL)  the  measured  time  in  seconds 
TEST.TIME.INITIAL  :  DURATION  ;  -  ditto  for  TEST 
TEST_TIME.FINAL  :  DURATION  ; 

TEST_DURATION  :  DURATION  ; 

--  WALL  time  variables 


WALL_CONTROL_TIME_INITIAL  :  DURATION  ;  --  sampled  from  CLOCK  at  beginning 
WALL_CONTROL_TIME_FINAL  :  DURATION  ;  —  sampled  from  CLOCK  ot  end 
WALl_CONTROL_DURaiIOn  ;  DURATION  ;  --  (FINAL-INITIAL)  measured  time  in  seconds 
WALL_TEST_TIME_INITIAL  :  DURATION  ;  —  ditto  for  TEST 
WALL_TEST_TIME.FINAL  :  DURAHON  ; 

WALL_TEST_OORATION  :  DURATION  ; 

MINIMUM_TIME  :  DURATION  :=  1.0  ;  --  required  minimum  value  of  test  time 
TEMP.TIME  :  FLOAT  ;  --  for  scaling  to  microseconds 
ITERATION.COUNT  :  ITERATION.COUNTS  ;  -  change  to  moke  timing  stable 

CHECK  :  INTEGER  ;  --  saved  from  STOP.TEST  call  for  scaling 

procedure  START.CONTROL  is 
begin 

CONTROL.TIME. INITIAL  :=  CPU.TIME.CLOCK  ; 

WALL_CONTROL_TIME_INITIAL  :=  CALENDAR. SECONDS(CALENDAR. CLOCK)  ; 
end  START.CONTROL  ; 


procedure  STOP.CONTROL  (  GLOBAL  :  INTEGER  ; 

CHECK  :  INTEGER  )  is 


begin 

CONTROL.TIME.FINAL  :=  CPU.TIME.CLOCK  ; 

CONTROL.DURATION  :=  CONTROL.TIME.FINAL  -  CONTROL.TIME.INIHAL 
WALL.CONTROL.TIME.FINAL  :=  CALENDAR. SECONOS(CALENDAR. CLOCK)  ; 
WALL.CONTROL.DURATION  :=  WALL.CONTROL.TIME.FINAL  - 

WALL.CONTROL.TIME.INITIAL  ; 


if  CHECK  /=  GLOBAL  then 

TEXT.IO.PUT.LINE  (  "  Fix  control  loop  before  making  measurements.”  )  ; 
TEXT.IO.PUT.LINE  (  INTEGER 'IMAGE  (  GLOBAL  )  &  "  =  GLOBAL  "  )  ; 
raise  PROGRAM.ERROR  ; 
end  if  ; 

TEXT.IO.PUT.LINE  (  "Iteration  "  &  INTEGER 'IMAGE  (  ITERATION.COUNT  )  )  ; 
DURATION.IO.PUT  (  CONTROL .TIME.INITIAL  ); 

DURATION.IO.PUT  (  CONTROL.TIME.FINAL  ); 

DURATION.IO.PUT  (  CONTROL.DURATION  ); 

TEXT.IO.NEW.LINE  ; 
end  STOP.CONTROL  ; 

procedure  START.TEST  is 
begin 

TEST.TIME.INITIAL  :=  CPU.TIME.CLOCK  ; 

WALL.TEST.TIME.INITIAL  CALENDAR . SECONDS(CALENOAR .CLOCK)  ; 

end  START.TEST  ; 

procedure  STOP.TEST  (  GLOBAL  :  INTEGER  ; 

CHECK  :  INTEGER  )  is 


begin 
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TEST_TIME_FINAL  :=  CPU_TIME_CLOCK  ; 

TEST_OURATION  :=  TEST_TIME_FINAL  -  TEST_TIME_INITIAL  ; 
WALL_TEST_TIME_FINAL  CALENDAR. SECONDSCCALENDAR. CLOCK)  ; 
WALL_TEST_DURATION  :=  WALL_TEST_TIME_FIMAL  -  IIALL_TEST_TIME_INITIAL 


ITERATION. CHECK  :=  CHECK  ; 
if  CHECK  /=  GLOBAL  then 

TEXT_IO.PUT_LINE  C  "  Fix  test  loop  before  making  measurements.”  ) 
TEXT_IO.PUT_LINE  C  INTEGER 'IMAGE  C  GLOBAL  )  &  "  =  GLOBAL  "  )  ; 
raise  PROGRAM.ERROR  ; 
end  if  ; 
end  ST0P_TEST  ; 


procedure  FEATURE_TIMES  (  CPU.TIME  :  out  DURATION  ; 

WALL.TIME  :  out  DURATION  )  is 


begin 


--  compute  scaled  results 


begin 

TEMP_TIME  ;=  FLOAT  C  TEST_DURATION  -  CONTROL .DURATION  )  ; 
TEMP.TIME  :=  (1_000_000.0  *  TEMP.TIME)  / 

C  FLOAT  (  ITERATION.COUNT  )  *  FLOAT  (CHECK)  ); 
CPU.TIME  :=  DURATION  (  TEMP. TIME  )  ; 
exception 

when  others  =>  --  bail  out  if  trouble  in  conversion 

CPU.TIME  0.0  ; 
end  ; 


begin 

TEMP.TIME  :=  FLOAT  (  WALL.TEST.DURATION  -  WAlL.CONTROL.DURATION  ) 
TEMP.TIME  :=  (1.000.000.0  *  TEMP.TIME)  / 

(  FLOAT  (  ITERATION.COUNT  )  *  FLOAT  (CHECK)  ); 
WALL.TIME  :=  DURATION  (  TEMP.TIME  )  ; 
exception 

when  others  => 

WALL.TIME  :=  0.0  ; 
end  ; 

end  FEATURE.TIMES  ; 


procedure  INITIALIZE  (  ITERATION.COUNT  :  out  INTEGER  )  is 
begin 

ITERATION.COUNT  1  ; 

ITERATION. ITERATION.COUNT  1  ; 

end  INITIALIZE  ; 

procedure  TEST.STABLE  (  ITERATION.COUNT  :  in  out  INTEGER  ; 

STABLE  :  out  BOOLEAN  )  is 

begin 

if  TEST.DURATION  >  MINIMUM.TIME  then 
STABLE  :=  TRUE  ; 

elsif  ITERATION.COUNT  >=  16384  then 

TEXT.IO.PUT.LINE  (  "*••••  INCOMPLETE  MEASUREMENT  •••••■•  )  ; 
STABLE  :=  TRUE  ; 
else 

ITERATION.COUNT  :=  ITERATION.COUNT  +  ITERATION.COUNT  ; 
ITERATION. ITERATION.COUNT  ;=  ITERATION.COUNT  ; 

STABLE  :=  FALSE  ; 

END  IF; 

end  TEST.STABLE  ; 


begin 

if  SYSTEM. TICK  ♦  100  >  MINIMUM.TIME  then 
MINIMUM.TIME  ;=  SYSTEM. TICK  •  100  ; 
end  if; 


if  DURATION 'SMALL  ♦  100  >  MINIMUM.TIME  then 
MINIMUM.TIME  :=  DURATION 'SMALL  »  100  ; 


end  if; 
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--  MINIMUM_TIME  is  now  the 


larger  of  1.0  second, 

100*SYSTEM.TICK, 
100*DURATION' SMALL 


CONTROL_DURATION  :=  0.0  ; 
WALL_CONTROL_DURATION  :=  0.0  ; 

end  ITERATION  ; 


A000091 
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"DHRYSTONE"  Benchmark  Program 

Version  ADA/1 

Date:  04/15/84 

Author:  Reinhold  P.  Weicker 

--  As  published  in  Communications  of  ACM,  October  1984  Vol  Z7  No  10 


--  The  following  progrom  contoins  statements  of  a  high-level  programming 
--  language  CAda)  in  a  distribution  considered  representative: 

assignments  53* 

control  statements  32* 

procedures,  function  call  15* 

--  100  statements  are  dynamically  executed.  The  program  is  balanced  with 
--  respect  to  the  three  aspects: 

-  statement  type 

-  operand  type  (for  simple  data  types) 

-  operand  access 

operand  global,  local,  parameter,  or  constant. 

--  The  combination  of  these  three  aspects  is  bolanced  only  opproximately . 

--  The  program  does  not  compute  anything  meaningful,  but  it  is  syntactically 
--  and  semanticolly  correct.  All  variables  have  a  value  assigned  to  them 
--  before  they  are  used  as  a  source  operand 


package  global.def  is 


--  global  definintions 

type  Enumeration  is  (ident_l,ident_2,ident_3,ident_4,ident_5): 

subtype  one_to_thirty  is  integer  range  1..30; 
subtype  one.to^fifty  is  integer  range  1..50; 
subtype  capital_letter  is  character  range  'A'..'Z'; 

type  String_30  is  array(one_to_ thirty)  of  character; 
pragma  pack(string_30); 

type  array_l_dim_integer  is  array  (one_to_fifty)  of  integer; 
type  array_2_dim_integer  is  array  Cone_to_fifty, 

one_to_ fifty)  of  integer; 

type  record_type(discr:enumeration:=ident_l); 


type  record_pointer  is  access  record_type; 


type  record_type(discr:enumeration:=ident_l)  is 


record 

pointer.comp: 
case  discr  is 
when  ident_l 


enum_comp: 
int_comp; 
string_comp : 
when  i dent. 2  => 
enum_comp_2: 
string_comp_2 : 


record. pointer; 

--  only  this  variant  is  used, 

--  but  in  some  cases  discriminant 

--  checks  are  necessary 

enumeration; 

one.to.fifty ; 

string_30; 

enumeration; 

string_30; 
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when  others  => 
chor_coinp_l, 

char_comp_2:  character; 

end  case; 
end  record; 

end  global.def; 

with  global_def; 
use  global _def; 

package  pack_l  is 


procedure  proc_0; 

procedure  proc_l(pointer_par_in:  in  record_pointer); 
procedure  proc_2(int_par_in_out :  in  out  one_to_fifty); 
procedure  proc_3(pointer_par_out:  out  record_pointer); 

int_glob:  integer; 

end  pack_l; 

with  global_def; 
use  globol.def; 

package  pack_2  is 


procedu  re 

proc_6  (enum_par_in; 

in 

enumeration; 

enum_par_out : 

out 

enumerotion); 

procedure 

proc_7  Cint_par_in_l, 
int_par_in_2: 

in 

one.to.fifty ; 

int_par_out: 

out 

one_to_fifty) 

procedure  proc_8  (array_par_in_out_l:  in  out  orray_l_dim_integer; 

array_par_in_out_2:  in  out  arroy_2_dira_integer; 
int_par_in_l, 

int_par_in_2:  in  integer); 


function  func.l  (char_par.in.l , 
char_par_in_2: 


in  capital_letter) 

return  enumerotion; 


function  func_2  (string_par_in_l, 
string_par_in_2: 


in  string_30) 

return  boolean; 


end  pack_2; 

with  global_def,  pack_l; 
use  global_def; 

procedure  A000091  is  --  Dhrystone 


begin 

pack_l .proc_0;  --  proc_0  is  actually  the  main  program,  but  it  is 

--  part  of  a  package,  and  a  program  within  a 
--  package  can  not  be  designated  as  the  main 
--  program  for  execution.  Therefore  proc_0  is 
--  activated  by  a  call  from  "main", 

end  A000091  ; 

with  global_def ,pack_2; 
use  global_def; 
with  cpu_time_clock ; 
with  text.io; 
with  duration.io; 


packoge  body  pack_l  is 
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bool_glob; 

char_glob_l, 

chor_glob_2: 

array_glob_l: 

array_glob_2: 

pointer_glob, 

poi nter_glob_next : 


boolean; 

character; 

a r ray_ ntege r ; 
a  r  ray_2_dini_i  ntege  r ; 

record.pointer; 


start_time  :  duration  ; 
stop_titne  :  duration  ; 
iteration_count  :  constant  :=  10_000  ; 


procedure  proc_4; 
procedure  proc_5; 


procedure  proc_0 
is 

int_loc_l, 

int_loc_2, 

int_loc_3: 

char_loc ; 

enuin_loc : 

string_loc_l, 

string_loc_2: 


one_to_fi  fty; 
cha racter; 
enume ration; 

string_30; 


begin 

--  initializations 

pack_l.pointer_glob_next  :=  new  record_type; 


pack_l.pointer_glob  :=  new  record  type 

■c 

pointer.comp  =>  pock_l.pointer_glob_next , 

discr  =>  ident.l, 

enunucomp  =>  ident_3, 

int_comp  =>  40, 

string.comp  =>  "DHRYSTONE  PROGRAM,  SOME  STRING" 

): 

string_loc.l  :=  "OHRYSTONE  PROGRAM,  I'ST  STRING”; 


--  start  timer  here 


start.time  ;=  cpu_time_clock  ; 
for  i  in  1  . .  iteration_count  loop 

proc_5; 

proc_4; 

--  char_glob.l  =  'A',  char_glob_2  =  'B',  bool_glob  =  folse 

int_loc_l  :=  2; 
int_loc_2  :=  3; 

string_loc_2  :=  "OHRYSTONE  PROGRAM,  2'NO  STRING"; 
enum_loc  :=  ident_2  ; 

bool.glob  :=■  not  pack_2.  func_2C  string_loc_l,string_loc_2); 

--  bool_glob  =  true 

while  int_loc_l  <  int_loc_2  loop  --loop  body  executed  once 
pragma  TA_L00P_B0UNDS(1, 1); 
int_loc_3  :=  5  •  int_loc_l  -  int_loc_2; 

--  int_loc_3  =  7 

pack_2. proc_7(int_loc_l,int_loc_2, int_loc_3); 
int_loc_3  ^  7 

int_loc_l  :=  int_loc_l  +  1; 
end  loop; 

--  int_loc_l  =  3 

pack_2.proc_8Corray_glob_l ,array_glob_2,int_loc_l,int_loc_3); 

--  int_glob  =  5 
proc_l(pointer_glob); 

for  char_index  in  ' A' . .Char_glob_2  loop  --loop  body  executed  twice 
if  enum.loc  =  pack_2  .func_l(char_index, 'C  ) 
then  --  not  executed 
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pac  k_2 . p  roc_6Ci dent_l , enum_loc) ; 
end  if; 
end  loop; 

--  enuiii_loc  =  ident_l 

--  int_loc  =  3,  int_loc_2  =  3,  int_loc_3  =  7 
int_loc_3  :=  int_loc_2  •  int_loc_l; 
int_loc_2  :=  int_loc_3  /  int_loc_l; 

int_loc_2  7  *  (  int_loc_3  -  int_loc_2  )  -  int_loc_l; 
proc_2Cint_loc_l); 

end  loop  ; 

stop_time  :=  cpu_tinie_clock  ; 
text_io. new_l ine ; 
text_io.new_line; 

text_io.put_lineC"Test  Nome:  4000091  Class  Name:  Composite"); 

text_io.putC'  "); 

duration_io.putC(stop_time-start_time)*1000/iteration_count); 
text_io.put_line("  is  time  in  milliseconds  for  one  Dhpystone"); 
text_io.put_lineCTest  Description:"); 

text_io.put_lineC'  Reinhold  P.  Weicker's  DHRYSTONE  composite  benchmark"); 
text_io.new_line; 


--  stop  timer  here 


end  proc_0; 

procedure  proc_lCpointer_par_in:  in  record_pointer)  is  --  executed  once 
next_record:  record.type 

renames  pointer_par_in.pointer_comp.all ;  --  pointer_glob_next .all 

begin 

next_record  :=pointer_glob.all; 
pointer_par_in.int_comp  :=  5; 
next_record. int_comp  :=  pointer_par_in.int_cofflp; 
next_record . poi nter_comp : =  poi nter_par_in. poi nter_comp ; 
proc_3Cnext_record . poi nter.comp) ; 

--  next_record.pointer_glob.pointer_comp  =  pointer_comp.next 
if  next_record.discr  «  ident_l 
then  --  executed 

next_record.int_comp  :=  6; 

pac  k_2 .  proc_6Cpointe  r_pa  r_i  n .  enum_comp ,  next_  record .  enum_comp') ; 
next_record.pointer_comp  :=  pointer_glob.pointer_comp; 
pack. 2 . proc_7Cnext_record . int_comp, 10, next_record . int_comp) ; 

else 

pointer_par_in.all  :=  next_record; 
end  if; 
end  proc_l; 

procedure  proc_2  (  int_par_in_out :  in  out  one_to_fifty) 
is  --  executed  once 

--  in_par_in_out  =  3  becomes  7 
int_loc  :  one_to_fifty; 
enum_loc  :  enumeration; 
begin 

int_loc  ;=  int_par_in_out  +  10; 
loop 

pragma  TA_L00P_B0UNDS(1,2); 
if  char_glob_l  =  'A' 
then 

int_loc  ;=  int_loc  -  1; 
int_par_in_out  :=  int_loc  -  int_glob; 
enum.loc  :=  ident_l;  --  true 
end  if; 

exit  when  enum.loc  =  ident_l;  --  true 
end  loop; 
end  proc_2: 

procedure  proc_3(pointer_par_out :  out  record_pointer) 
is  --  executed  once 

--  pointer_par_out  becomes  pointer_glob 

begin 

if  pointer.glob  /=  null 
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then  --  executed 

pointer_par_out  :=  pointer_g\ob.pointer_comp; 

else 

int_glob  :=  100; 
end  if; 

pock_2.proc_7(10,int_glob,pointer_glob.int_comp); 
end  proc_3; 

procedure  proc_4 
is 

bool_loc  :  boolean; 
begin 

bool_loc  :=  char_glob_l  =  'A'; 
bool_loc  :=  bool_loc  or  bool_glob; 
char_glob_2  :=  'B'; 
end  proc_4; 

procedure  proc_5 
is 

begin 

char_glob_l  :=  'A'; 
bool.glob  :=  false; 
end  proc.S; 

end  pack_l; 

with  global_def ,pack_l;  use  global_def; 
package  body  pock_2  is 

function  func_3Cenum_par_in:  in  enumeration)  return  boolean; 

--  forward  declaration 

procedure  proc.6Cenura_par_in:  in  enumeration; 

enum_par_out:  out  enumerotion)  is 

begin 

enum_par_out  :=  enum_par_in; 
if  not  func_3Cenum_par_in)  then 
enum.par.out  :=  ident_4; 
end  if; 

case  enuffl_par.in  is 

when  ident.l  *>€num_par_out  :=  ident.l; 
when  ident_2  =>if  pack_l.int_glob>100 

then  enum_par_out  :=  ident.l; 
else  enum.par.out  ident_4; 
end  if; 

when  ident.3  =>€num.par_out  ident_2;  --  executed 
when  ident_4  =>null; 
when  ident.S  =>enum_par_out  :=  ident_3; 
end  case; 
end  proc_6; 

procedure  proc_7Cint_par_in_l, 

int_par_in_2;  in  one.to.fifty ; 
int.par.out:  out  one.to.fifty)  is 

int.loc  ;  one.to.fifty; 
begin 

int.loc  :=  int.par.in.l  +  2; 
int.par.out  :=  int.par.in.2  +  int.loc; 
end  proc_7; 

procedure  proc_8  (array.par.in.out.l:  in  out  orray.l.dim.integer; 

array_par.in.out. 2;  in  out  array.2.dim_integer ; 
int.par.in.l, 

int.par.in_2:  in  integer) 

is 

int.loc:  one.to.fifty; 
begin 

int.loc  :=  int.par.in.l  +  5; 
array_par_in_out_l(int_loc)  :=  int_par_in_2; 
array.par.i n_out_l(int_loc  +  1)  := 

array.par.in_out.l(int.loc) 
array_par_in_out_l(int_loc  -r  30)  :=  int.loc; 
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for  int.i.idex  in  int_loc . .  int^loc  +  1  loop  --  loop  body  executed  twice 
pragma  TA_L00P_B0UNDS(2,2); 
array_par_in_out_2(int_loc,int_index)  :=  int_loc  ; 
end  loop; 

array_par_in_out_2(int_loc ,int_loc-l)  := 

array_par_in_out_2(int_loc,int_loc-l)  +  1; 
orray_par_in_out_2Cint_loc  +  20,int_loc)  := 

arroy_par_in_out_lCint_loc); 

pack_l. int_glob  :=  5; 
end  proc_8; 

function  func_l  Ccbar_par_in_l, 

char_par_in_2;  in  capital_letter)  return  enumeration 
is 

char_loc_l,  char_loc_2  •  capital_tetter; 
begin 

char_loc_l  :=  char_par_in_l; 
char_loc_2  ;=  char_loc_l; 
if  char_ioc_2  /=  char_par_in_2  then 
return  ident_l; 

else 

return  ident_2; 
end  if; 
end  func_l; 

f' 'net ion  func.2(string_par.in_l , 

string_par_in_2:  in  string.30)  return  booleon 

IS 


int.loc:  one.to_thi rty ; 
char.loc:  capital .letter ; 


‘’egin 

int.loc  :=  2; 

while  int.loc  <=  2  loop 

progmo  TA.LOOP.BOUNDSCl.l); 
if  func_lCstring_por_in_lCint_loc), 

string.par.in  2(int_loc+l))  =  'dent.l  then 
char.loc  :=  'A'; 
int.loc  :=  int.loc  +  1; 
end  if; 
end  loop; 

if  char.loc  >='W'  and  char.loc  <  'Z'  then 
int.lo..  :=  7; 
end  if; 

if  char.loc  =  'X'  then 
return  true; 

else 

if  string.pnr.in.l  >  st  •ing_par_in_2  then 
int.loc  ;=  int.loc  +  7; 
return  true; 

el  s. 

return  false; 
end  if; 
end  if; 
end  func_2; 


function  func_3Cenum_par_in:  in  enumeration)  return  boolean 

IS 


enum.loc:  '■.uu.  jration ; 
begin 

enum.loc  enum  par.in; 
if  enum.loc  =  ident.3  then 
return  true; 
end  if; 
end  func.3; 


end  pack.Z ; 

--  Ada  version  of  Whetstone  Be  ;'hmarl  Program 
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This  must  be  edited  to  "with"  the  compiler  suppliers  math  routines 
SIN,  COS,  ATAN,  SQRT,  EXP  ond  LOG 

These  results  may  be  interesting  to  compare  to  Z000093  that  uses 
a  physically  included,  all  Ada  set  of  math  routines 
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WHETADA.ADA  distributed  as  A000092.AOA 

Ada  version  of  the  Whetstone  Benchmark  Program. 

Reference:  "Computer  Journal"  February  1976,  poges  43-49 

for  description  of  benchmark  and  ALGOL60  version. 
--  Note:  Procedure  POUT  is  omitted. 

--  From  Timing  Studies  using  a  synthetic  Whetstone  Benchmark 
by  Sara  Harbaugh  and  John  A.  Forakis 


--  Authors  Disclaimer 

--  "  The  Whetstone  measure  deals  only  with  the  most  basic  scientific/  -- 
--  computational  aspects  of  the  languages  and  computers  ond  no  general  -- 
conclusions  should  be  drawn  from  this  work.  Application  specific 
--  benchmarks  should  be  written  and  run  by  anyone  needing  to  draw 
--  conclusions  reguording  suitability  of  languages,  compilers  ond 
hordwore.  This  data  is  reported  to  stimulate  interest  and  work  in 
run  time  benchmarking  and  in  no  way  is  meant  to  influence  onyone's  -- 
choice  of  languages  or  software  in  any  situation  " 


with  CPU_TIME_CLOCK  ; 
with  TEXT_IO;  use  TEXT.IO; 

--  Change  the  following  line  to  use  the  compiler  vendors  or  manufacturers 
--  math  library. 

with  MATH_LIB;  use  MATH_LIB;  --  manufacturers  routines  C  Meridian  for  Moc  ) 
procedure  A000092A  is 

-progmo  SUPPRESS(ACCESS_CHECK);  00  NOT  USE  PRAGMA  SUPPRESS  for  PIWG 

-pragma  SUPPRESS(OISCRIMINANT.CHECK); 

--pragma  SUPPRESS(INOEX_CHECK) ; 

--pragma  SUPPRESSCLENGTH.CHECK); 

--pragma  SUPPRESSCRANGE.CHECK); 

-pragma  SUPPRESS(0IVISI0N_CHECK); 

-pragma  SUPPRESS(0VERFL0W_CHECK): 

--pragma  SUPPRESSCSTORAGE.CHECK); 

--pragma  SUPPRESS(ELABORATION_CHECK); 

package  REAL_I0  is  new  FL0AT_I0(FL0AT);  use  REAL. 10; 

subtype  CYCLES  is  INTEGER  range  10.. 50; 

procedure  WHETSTONE(NO.OF_CYCL ES  :  in  CYCLES; 

START_TIME.STOP.TIME:  out  FLOAT)  is 

--  Calling  procedure  provides 

--  the  encompassing  loop  count,  NO.OF.CYCLES. 

type  VECTOR  is  orray  (INTEGER  range  <>)  of  FLOAT; 

X1,X7,X3,X4,X,Y,Z  :  FLOAT; 

El  :  VECTORd.  .4); 

J,K,L  :  INTEGER; 


Set  constants 

T 

:  constant 

= 

0.499975; 

T1 

:  constant 

= 

0.50025; 

T7 

:  constant 

= 

2.0; 

-■ 

Compute  the 

execution  frequency  for  the  benchmark  modules 

N1 

:  constant 

0;  -Module  1  not  executed 

N7 

:  constant 

120; 

N3 

:  constant 

140; 

N4 

:  constant 

= 

3450; 

NS 

;  constant 

= 

0;  --  Module  5  not  executed 

N6 

:  constant 

2100; 

N7 

;  constant 

= 

320; 

Ng 

:  constant 

= 

8990; 

N9 

:  constant 

= 

6160; 

N10 

:  constant 

= 

0;  --  Module  10  not  executed 

Nil 

:  constant 

:  =: 

930; 

76 


procedure  PA(E:  in  out  VECTOR)  is 
--  tests  computations  with  an  array  as  o  parameter 
}  :  INTEGER; 

--  T,T2  :  FLOAT  are  global  variables 
begin 
J:=0; 
loop 

pragma  TA_LOOP_BOUNDSC6,6); 

ECD  :=  CECD  +  EC2)  +  EC3)  -  EC4))  ♦  T; 

E(2)  (E(l)  +  EC2)  -  E(3)  +  E(4))  •  T; 

EC3)  :=  CECD  -  EC2)  +  EC3)  +  EC4))  *  T; 

EC4)  :=  C-ECD  +  EC2)  +  EC3)  +  EC4))  /  T2 
J  :=  J  +  1; 


end  PA; 


exit  when  j  >=  6; 
end  loop; 


procedure  P0  is 

--  tests  computations  with  no  parameters 
--  T1,T2  :  FLOAT  are  global 
--  El  :  VECTORCl. -4)  is  global 
--  J,K,L  :  INTEGER  ore  global 
begin 

EICJ)  •=  EICK); 

EICK)  :=  EICL); 

EICL)  :=  EICJ); 
end  P0; 


procedure  P3CX,Y:  in  out  FLOAT;  2  :  out  FLOAT)  is 
--  tests  computations  with  simple  identifiers  as  parameters 
--  T,T2  :  FLOAT  are  global 
begin 

X  ;=  T  •  CX  +  Y); 

Y  :=  T  •  CX  +  Y); 

Z  :=  CX  +  Y)  /  T2; 
end  P3; 


begin 

START.TIME  :=  FLOATCCPU.TIME_CLOCK);  --Get  Whetstone  start  time 
CYCLE.LOOP: 

for  CYCLE.NO  in  1. .NO_OF.CYCLES  loop 

-  Module  1  :  computations  with  simple  identifiers 


XI 

= 

1.0; 

X2 

3 

-1.0 

X3 

= 

-1.0 

X4 

= 

-1.0 

for 

I 

in  1 

XI  :=  (XI  +  X2  +  X3  -  X4)  »  T; 

X2  :=  CXI  +  X2  -  X3  +  X4)  ♦  T; 

X3  :=  CXI  +  X2  +  X3  +  X4)  •  T; 

X4  :=  C-Xl  X2  +  X3  +  X4)  *  T; 
end  loop; 

--  end  Module  1 

--  Module  2:  computations  with  arroy  elements 
El(l)  :=  1.0; 

El(2)  :=  -1.0; 

El(3)  :=  -1.0; 

E1C4)  :=  -1.0; 

for  I  in  1. .N2  loop 

El(l)  :=  (El(l)  4^  El(2)  +  El(3)  -  El(4))  *  T; 

El(2)  (EICD  *  El(2)  -  El(3)  +  El(4))  •  T; 

E1C3)  :=  (El(l)  -  El(2)  +  El(3)  +  El(4))  •  T; 

El(4)  ;=  (-El(l)  >  El(2)  t  E1C3)  +  £1(4))  •  T; 
end  loop; 

-  -  end  Module  2 
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Module  3  :  passing  on  array  as  a  parmeter 
for  I  in  1. .N3  loop 
PACED: 
end  loop; 
end  Module  3 

Module  4  :  performing  conditional  jumps 
J  :=  1; 

for  I  in  1. .N4  loop 
if  J=1  then 
J  :=  2; 

else 

J  :=  3; 
end  if; 
if  J>2  then 
J  :=  0; 

else 

J  :=  1; 
end  if; 
if  J<1  then 
J  :=  1; 

else 

J  :=  0; 
end  if; 
end  loop; 
end  Module  4 

Module  5  :  omitted 

Module  6  ;  performing  integer  orithmetic 
J  :=  1; 

K  :=  2; 

L  :=  3; 

for  I  in  1. .N6  loop 

J  :=  J  •  CK-J)  •  (L-K); 

K  :=  L*K  -  CL-J)  •  K; 

L  :=  CL-K)  »  CK+D; 

El(l-lj  :=  FLOAT(}+K+L); 

EICK-D  :=  FL0AT(3*K*L); 
end  loop; 
end  Module  6 

Module  7  :  performing  computations  using  trigonometric 
functions 

X  :=  0.5; 

Y  ;=  0.5; 

for  I  in  1. .N7  loop 

X  :=  T*ATAN(T2«SIN(X)*COS(X)/(COSCX+Y)+COSCX-Y)-1.0)); 
Y  :=  T«ATAN(T2*SIN(Y)*COS(Y)/CCOS(X+Y)+COS(X-Y)-1.0)); 
end  loop; 
end  Module  7 

Module  8  :  procedure  calls  with  simple  identifiers  as 
parameters 

X  :=  1.0; 

Y  ;=  1.0; 

Z  :=  1.0; 

for  I  in  1..N8  loop 
P3(X,Y,Z); 
end  loop; 
end  Module  8 

Module  9  :  array  reference  and  procedure  calls  with  no 
pa rameters 

J  :=  1; 

K  :=  2; 

I  :=  3; 

Eld)  1.0; 

E1C2)  ;=  2.0; 

El(3)  :=  3.0; 
for  I  in  1. .N9  loop 
P0: 

end  loop; 


--  end  Module  9 
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--  Module  10  :  integer  arithmetic 
J  :=  2; 

K  :=  3; 

for  I  in  1. .N10  loop 
J  :=  J  +  K; 

K  :=  K  +  J; 

J  ;=  K  -  J; 

K  ;=  K  -  J  -  J; 

end  loop; 

--  end  Module  10 

--  Module  11  :  performing  computottons  using  stondard 
mathematical  functions 

X  :=  0.75; 

for  I  in  1. .Nil  loop 

X  :=  SQRTCEXP(LN(X)/T1)); 
end  loop; 

--  end  Moudle  11 

end  loop  CYCLE_L00P; 

STOP_TIME  :=  FLOAT(CPU_TIME_CLOCK);  --Get  Whetstone  stop  time 
end  WHETSTONE; 

procedure  COMPUTE_WHETSTONE_KIPS  is 

--  Variables  used  to  control  execution  of  benchmark  and  to 
--  compute  the  Whetstone  rating  ; 

NO_OF_RUNS  :  constant  ;=  5;  --  Number  of  times  the  benchmark  is  executed 

NO_OF_CYCLES  :  INTEGER;  --  Number  of  times  the  group  of  benchmark 
--  modules  is  executed 

--  I  :  INTEGER; 

--  Embedded  (as  10)  in  ”N’’  constonts  at  beginning  of  WHETSTONE  proc 
--  Factor  weighting  number  of  times  each  module  loops 
--  A  value  of  ten  gives  a  total  weight  for  modules  of 
--  approximately  one  million  Whetstone  instructions 
START. TIME  :  FLOAT; 

--  Time  at  which  execution  of  benchmark  modules  begins 
ST0P_TIME  :  FLOAT; 

--  Time  at  which  execution  of  benchmark  modules  ends 
--  (time  for  NO.OF.CYCLES) 

ELAPSEO-TIME  :  FLOAT; 

--  Time  between  START.TIME  and  ST0P_TIME 
MEAN_TIME  :  FLOAT;  --  Average  time  per  cycle 
RATING  :  FLOAT;  --  Thousands  of  Whetstone  instructions  per  sec 
MEAN.RATING  :  FLOAT;  --  Average  Whetstone  rating 
INT_RATING  :  INTEGER;  --  Integer  value  of  KWIPS 

begin 

NEW.LINE; 

PUT.LINE 

("Test  Name:  A000092  Class  Name:  composite"); 

MEAN.TIME  :=  0.0; 

MEAN.RATING  :=  0.0; 

NO_OF. CYCLES  :=  10; 

RUN.LOOP: 

for  RUN.NO  in  1 . . NO_OF_RUNS  loop 

--  Call  the  Whetstone  benchmark  parocedure 
WHETSTONE(NO.OF.CYCLES, START.TIME, STOP.TIME); 

--  Compute  and  write  elapsed  time 
ELAPSED.TIME  :=  STOP.TIME  -  START.TIME; 

--  Sum  time  in  milliseconds  per  cycle 
MEAN.TIME  :=  MEAN.TIME  +  (ELAPSEO.TIME* 1000.0)/ 

FLOAT(NO.OF_CYCLES); 

--  Calculate  the  Whetstone  noting  bosed  on  the  time  for 
--  the  number  of  cycles  just  executed  and  write 
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RATING  :=  (1000.0  »  FLOAT(NO_OF.CYCLES)yELAPSED_TIME; 

--  Sum  Whetstone  rating 
MEAN.RATING  :=  MEAN.RATING  +  RATING; 

INT_RATING  :=  INTEGERCRATING); 

--  Reset  N0_0F_CYCLES  for  next  run  using  ten  cycles  more 
NO_OF_CYCLES  N0_0F_CYCLES  +  10; 
end  loop  RUN.LOOP; 

--  Compute  average  time  in  millieseconds  per  cycle  and  write 
MEAN.TIME  :=  MEAN_TIME/FLOAT(NO_OF_RUNS); 

NEW_LINE;  PlFTC'Average  time  per  cycle  : 
PUT(MEAN_TIME,5,2,0);  PUT.LINEC’  milliseconds"): 

--  Calculate  average  Whetstone  rating  and  write 
MEAN_RATIN6  :=  MEAN_RATING/FLOAT(NO_OF_RUNS); 

INT_RATING  :=  INTEGERCMEAN^RATING); 

NEW_LINE;  PUT("Average  Whetstone  rating  :  "); 
PUT_LINE(INTEGER'IMAGE(INT.RATING)  &  "  KWIPS"); 

NEW_LINE; 

NEW.LINE; 

end  COMPUTE_WHETSTONE_KIPS; 
begin 

COMPUTE_WHETSTONE_KIPS ; 
end  A000092A; 
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--  PERFORMANCE  MEASUREMENT  :  task  creation  and  termination  time 

1  task  no  entry 

task  type  in  package,  no  select 

with  REMOTE.GLOBAL  ;  use  REM0TE_GL08AL  ; 
package  CREATE_PACK_1  is 
task  type  T1  is 
end  T1  : 

procedure  PI  ;  --  will  create  task,  run  task,  and  terminate  task 
end  CREATE_PACK_1  ; 

with  CREATE_PACK_1  ;  use  CREATE_PACK_1  ; 

with  REM0TE_GL0BAL  ;  use  REM0TE_GL0BAL  ;  --  control  optimization 
with  ITERATION  ;  --  obtain  stable  measurement 
with  PIWG_I0  :  --  output  results 

procedure  C000001  is  --  main  procedure  to  execute 

CPU_TIME  :  DURATION  ;  --  CPU  time  for  one  feature  execution 
WALL_TIME  :  DURATION  ;  --  WALL  time  for  one  feoture  execution 
CHECK_TIMES  :  constant  :=  100  ;  --  inside  loop  count  and  check 

ITERATI0N_C0UNT  :  ITERATION. ITERATI0N_C0UNTS  :  —  set  and  varied  by  ITERATION  package 
STABLE  :  BOOLEAN  ;  --  true  when  measurement  stable 


begin 

ITERATION. ST ART_C0NTR0L  ;  --  dummy  to  bring  in  poges  on  some  mochines 

delay  5.0  ;  --  wait  for  stable  enviornment  on  some  machines 

ITERATION. INITIALIZE  (  ITERATION.COUNT  )  ; 

loop  --  until  stable  measurement,  ITERATION_COUNT  increases  each  time 


--  Control  loop 


ITERATION. START.CONTROL  ; 

for  J  in  1  ..  ITERATION.COUNT  loop 


GLOBAL  0  ; 
for  INSIDE.LOOP  in 


GLOBAL 
REMOTE 
end  loop 


GLOBAL 


.  CHECK.TIMES  loop 
-ONE  ; 


end  loop  ; 

ITERATION. STOP-CONTROL  C  GLOBAL  ,  CHECK-TIMES  )  ; 


-  Test  loop 


--  establish  task  create  and  terminate  time 

ITERATION. START-TEST  ; 
for  J  in  1  ..  ITERATION-COUNT  loop 
GLOBAL  :=  0  ; 

for  INSIDE-LOOP  ml..  CHECK-TIMES  loop 

PI  ;  --  this  has  task  that  has  global  increment  and  coll  inside 
end  loop  ; 
end  loop  ; 

ITERATION. STOP-TEST  (  GLOBAL  ,  CHECK-TIMES  )  ; 

ITERATION. TEST-STABLE  (  ITERATION-COUNT  .  STABLE  )  ; 
exit  when  STABLE  ; 
end  loop  ; 

ITERATION. FEATURE-TIMES  (  CPU-TIME  ,  WALL-TIME  )  ; 


-  Printout 


PIWG_IO.PIWG_OUTPUT  (  "C000001"  ,  "Tasking"  , 

CPU_TIME  ,  WALL.TIME  ,  ITERATION_COUNT  , 

"  Task  creote  and  terminate  measurement  "  , 

"  with  one  task,  no  entries,  when  task  is  in  a  procedure"  , 

"  using  a  task  type  in  a  package,  no  select  statement,  no  loop,  "  )  ; 

end  C000001  ; 

package  body  CREATE_PACK_1  is 
task  body  T1  is 
begin 

GL03AL  :=  GLOBAL  +  A_0NE  ; 

REMOTE  ; 
end  T1  ; 

procedure  PI  is 

T  :  T1  ;  this  creates  the  task,  runs  task  to  completion  and  terminates 
begin 
nul  1  ; 
end  PI  ; 

end  CREATE_PACK_1  ; 
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--  PERFORMANCE  MEASUREMENT  :  task  creation  and  termination  time 

1  task  no  entry 

task  defined  and  used  in  procedure,  no  select 

with  REMOTE.GLOBAL  ;  use  REMOTE_GLOBAL  ; 
package  CREATE_PACK_2  is 

procedure  PI  ;  --  will  create  task,  run  task,  ond  terminate  task 
end  CREATE_PACK_2  ; 

with  CREATE_PACK_2  ;  use  CREATE_PACK_2  ; 

with  REMOTE_GLOBAL  ;  use  REMOTE_GLOBAL  ;  --  control  optimization 
with  ITERATION  ;  --  obtain  stable  measurement 
with  PIWG_IO  ;  --  output  results 

procedure  C000002  is  --  main  procedure  to  execute 

CPU_TIME  :  DURATION  ;  --  CPU  time  for  one  feature  execution 
WALL_TIME  :  DURATION  ;  --  WALL  time  for  one  feature  execution 
CHECK_TIMES  :  constant  :=  100  ;  --  inside  loop  count  and  check 

ITERATION.COUNT  :  ITERATION. ITERATION.COUNTS  ;  --  set  and  varied  by  ITERATION  package 
STABLE  :  BOOLEAN  ;  --  true  when  measurement  stable 

begin 

ITERATION. ST ART_CONTROL  ;  --  dummy  to  bring  in  pages  on  some  machines 

delay  0.5  ;  --  wait  for  stable  enviornment  on  some  machines 

ITERATION. INITIALIZE  (  ITERATION.COUNT  )  ; 

loop  --  until  stable  measurement,  ITERATION_COUNT  increases  each  time 


--  Control  loop 


ITERATION. START.CONTROL  ; 

for  J  in  1  ..  ITERATION.COUNT  loop 


GLOBAL  :=  0  j 

for  INSIDE. LOOP  in  1 


CHECK.TIMES  loop 


GLOBAL 

REMOTE 


=  GLOBAL  +  A.ONE 


end  loop  ; 
end  loop  ; 

ITERATION.STOP.CONTROL  (  GLOBAL  ,  CHECK.TIMES  ) 


Test  loop 


ITERATION. START.TEST  ; 
for  J  in  1  ..  ITERATION.COUNT  loop 
GLOBAL  :=  0  ; 

for  INSIOE.LOOP  in  1  ..  CHECK.TIMES  loop 

PI  ;  --  this  has  task  that  has  global  increroen'-  ond  call  inside 
end  loop  ; 
end  loop  ; 

ITERATION. STOP.TEST  (  GLOBAL  ,  CHECK.TIMES  ?  ; 

ITERATION. TEST.STABLE  C  ITERATION.COUNT  ,  STABLE  )  ; 
exit  when  STABLE  ; 
end  loop  ; 

ITERATION. FEATURE.TIMES  (  CPU.TIME  ,  WALL.TIME  )  ; 


--  Printout 

PIWG.IO.PIWG.OUTPUT  (  ••C000002"  ,  "Tasking"  , 

CPU.TIME  ,  WALL.TIME  ,  ITERATION.COUNT  , 

"  Task  create  and  terminate  time  measurement.  "  , 

”  with  one  task,  no  entries  when  tosk  is  in  o  procedure,"  , 

"  task  defined  and  used  in  procedure,  no  select  statement,  no  loop  "  )  ; 


end  C000002  ; 
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package  body  CREATE_PACK_2  is 
procedure  PI  is 

this  creates  the  task,  runs  task  to  completion  and  terminates 
execution  time  for  task  taken  out  by  control  loop 
task  T1  is 
end  T1  ; 

task  body  T1  is 
begin 

GLOBAL  :=  GLOBAL  +  A_0NE  ; 

REMOTE  : 
end  T1  ; 

begin 
nul  I  ; 
end  PI  ; 

end  CREATE_PACK_2  ; 
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--  PERFORMANCE  MEASUREMENT  :  operations  on  boolean  arrays 

arrays  are  NOT  packed 
operations  on  components  in  loop 

with  REMOTE_GLOBAL  ;  use  REMOTE_GLOBAL  ;  --  control  optimization 
with  ITERATION  ;  --  obtain  stable  measurement 

with  PIWG.IO  ;  --  output  results 

procedure  H000004  is  --  main  procedure  to  execute 

CPU.TIME  :  DURATION  ;  —  CPU  time  for  one  feoture  execution 

WALL_TIME  :  DURATION  ;  --  WALL  time  for  one  feature  execution 

CHECK_TIMES  :  constant  :=  100  ;  --  inside  loop  count  and  check 

ITERATION_COUNT  :  ITERATION. ITERATION_COUNTS  ;  —  set  and  varied  by  ITERATION  package 
STABLE  :  BOOLEAN  ;  --  true  when  measurement  stable 

--  Boolean  array  declarations 

type  UNPACKED_BIT_ARRAY  is  array  (  NATURAL  range  o  )  of  BOOLEAN; 

8IT_VALUE_1  :  BOOLEAN  :=  GLOBAL  >  0; 

BIT_VALUE_2  :  BOOLEAN  :=  GLOBAL  rem  2  =  0; 

BIT_VALUE_3  :  BOOLEAN  :=  GLOBAL  <=  1; 

subtype  UNPACKE0_16  is  UNPACKEO.BIT.ARRAY  (  0  ..  15  ); 

UNPACKED_1  :  UNPACKED.16  ;=  UNPACKED_16’C  0131619112115  =>  BIT_VALUE_1, 

11517111113  =>  BIT_VALUE.2, 
others  =>  BIT_VALUE_3  ); 

UNPACKED_2  ;  UNPACKE0_16  UNPACKE0.16‘ (  0..3  =>  BIT.VALUE.l, 

4. .12  =>  BIT.VALUE.2, 
others  =>  BIT.VALUE_3  ); 


begin  --  procedure  H000004 

ITERATION. START.CONTROL  ;  --  dummy  to  bring  in  pages  on  some  nxichines 

delay  0.5  ;  --  wait  for  stable  enviornment  on  some  machines 

ITERATION. INITIALIZE  (  ITERATION.COUNT  )  ; 

loop  --  until  stable  measurement,  ITERATION.COUNT  increases  each  time 

■-  Control  loop 

ITERATION. START.CONTROL  ; 
for  J  in  1  ..  ITERATION.COUNT  loop 
GLOBAL  :=  0  ; 

for  INSIDE.LOOP  ml..  CHECK.TIMES  loop 
GLOBAL  GLOBAL  +  A.ONE  ; 

REMOTE  : 
end  loop  ; 
end  loop  ; 

ITERATION. STOP.CONTROL  (  GLOBAL  ,  CHECK.TIMES  )  ; 

--  Test  loop 

ITERATION. START.TEST  ; 
for  J  in  1  . .  ITERATION.COUNT  loop 
GLOBAL  -.=  0  ; 

for  INSIDE.LOOP  ml..  CHECK.TIMES  loop 
GLOBAL  :=  GLOBAL  +  A.ONE; 
for  I  in  UNPACKED.lb'RANGE  loop 
UNPACKED.IC  I  )  ;=  UNPACKED.2(  I  )  xor  not  UNPACKED.IC  I  ); 
end  loop; 

for  I  in  UNPACKED.16'RANGE  loop 
UNPACKED.ZC  I  3  :=  UNPACKED.IC  I  )  or  UNPACKED_2C  I  ); 
end  loop; 

for  I  in  UNPACKED.ie 'RANGE  loop 

UNPACKED.IC  I  )  :=  notC  UNPACKED.IC  I  )  and  UNPACKED  2C  I  )  ); 
end  loop; 

REMOTE; 
end  loop  ; 
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end  loop  ; 

ITERATION. STOP.TEST  (  GLOBAL  ,  CHECK_TIMES  )  ; 

--  Be  sure  UNPACKED_1  has  been  computed 

if  UNPACKED_1C  GLOBAL  rera  16  )  then 
GLOBAL  ;=  A_0NE; 

REMOTE; 
end  if; 

ITERATION. TEST_STABLE  (  ITERATION_COUNT  ,  STABLE  )  ; 
exit  when  STABLE  ; 
end  loop  ; 

ITERATION. FEATURE_TIMES  (  CPU_TIME  ,  WALL.TIME  )  ; 

--  Printout 

PIWG_IO.PIWG_OUTPUT  (  "H000004"  ,  "Chapter  13"  . 

CPU_TIME  ,  WALL_TIME  ,  ITERATION_COUNT  , 

"  Time  to  perform  standard  boolean  operations  on  arrays  of  booleans. 
"  For  this  test  the  arrays  are  NOT  PACKED  with  the  pragma  'PACK.'"  , 
"  For  this  test  the  operations  are  performed  on  components  in  a  loop 

end  H0000e4  ; 
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--  PERFORMANCE  MEASUREMENT  :  Minimum  procedure  call  and  return  time 

procedure  local 
no  parameters 

with  REMOTE_GLOBAL  ;  use  REMOTE.GLOBAL  ; 
with  ITERATION  ; 
with  PIWG_I0  ; 

procedure  P000001  is  --  moin  procedure  to  execute 

CPU_TIME  :  DURATION  ; 

WALL_TIME  :  DURATION  ; 

CHECK_TIMES  ;  constant  :=  100  ; 

ITERATION.COUNT  :  ITERATION. ITERATION.COUNTS  ; 

ITS_0K  :  BOOLEAN  ; 


procedure  PROC_0  is  --  may  be  inlined  thus  zero  time 
begin 

GLOBAL  :=  GLOBAL  *■  A.ONE  ; 

REMOTE  ; 
end  ; 

begin 

ITERATION. START_C0NTR0L  ;  --  dummy  to  bring  in  pages  on  some  machines 

delay  0.5  ;  --  wait  for  stable  enviornment  on  some  machines 

ITERATION. INITIALIZE  (  ITERATION.COUNT  )  ; 

loop  --  until  stable  measurement,  ITERATION_COUNT  increases  each  time 


Control  loop 


ITERATION. START.CONTROL  ; 

for  J  in  I  ..  ITERATION.COUNT  loop 


GLOBAL  0  ; 
for  INSIDE.LOOP  in 


GLOBAL 
REMOTE 
end  loop 
end  loop  ; 

ITERATION . ST0P_C0NTR0L 


1  ..  CHECK.TIMES  loop 
GLOBAL  +  A_ONE  ; 


(  GLOBAL  ,  CHECK.TIMES 


)  : 


--  Test  loop 

ITERATION. START.TEST  ; 
for  J  in  1  ..  ITERATION.COUNT  loop 
GLOBAL  0  ; 

for  INSIDE.IOOP  ml..  CHECK.TIMES  loop 

PROC.0  ;  --  this  has  control  globol  increment  ond  coll  inside 

end  loop  ; 
end  loop  ; 

ITERATION. STOP.TEST  (  GLOBAL  ,  CHECK.TIMES  )  ; 

ITERATION. TEST.STABLE  (  ITERATION.COUNT  ,  ITS.OK  )  ; 
exit  when  ITS.OK  ; 
end  loop  ; 

ITERATION. FEATURE.TIMES  (  CPU.TIME  ,  WALl.TIME  )  ; 


--  Printout 

PIWG.IO.PIWG.OUTPUT  (  ^000001"  ,  "Procedure"  , 

CPU.TIME  -r  WALL.TIME  ,  ITERATION.COUNT  , 

"  Procedure  call  and  return  time  (  may  be  zero  if  automatic  inlining  ) 
"  procedure  is  local  "  , 

"  no  parometers  "  )  ; 
end  P000001  ; 
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--  PERFORMANCE  MEASUREMENT  :  procedure  call  and  return  time 

procedure  in  package 

ten  discrete  "in"  parameters 

packoge  PROC_PACKAGE_10  is 

procedure  PROC_0  (  Al,  A2,  A3,  A4,  AS,  A6,  A7,  A8,  A9,  A10  ;  in  INTEGER  )  ; 
end  PROC_PACKAGE_10  ; 

with  PROC_PACKAGE_10  ;  use  PROC_PACKAGE_10  ; 

with  REMOTE.GLOBAL  ;  use  REMOTE_GLOBAL  ;  --  control  optimization 
with  ITERATION  ;  obtain  stable  measurement 
with  PIWG_IO  ;  --  output  results 

procedure  P000010  is  --  main  procedure  to  execute 

CPU_TIME  ;  DURATION  ;  --  CPU  tir.e  for  one  feature  execution 
*ALL_TIME  :  DURATION  ;  --  WALL  time  for  one  feature  execution 
CHECK_TIMES  :  constant  :=  100  ;  --  inside  loop  count  ond  check 

ITERATION_COUNT  :  ITERATION . ITERATION.COUNTS  ;  --  set  and  varied  by  ITERATION  package 
STABLE  :  BOOLEAN  ;  --  true  when  measurement  stable 
Al  ;  INTEGER  :=  A_ONE  ; 

^2  ■.  INTEGER  :=  Al  +  A_0NE  ; 

A3  :  INTEGER  :=  A2  +  A.ONE  ; 

A4  ;  INTEGER  :=  A3  +  A.ONE  ; 

AS  :  INTEGER  ;=  A4  +  A.ONE  ; 

A6  ;  INTEGER  ;=  AS  +  A.ONE  ; 

A7  :  INTEGER  :=  A6  +  A.ONE  ; 

A8  :  INTEGER  :=  A2  +  A.ONE  ; 

A9  :  INTEGER  :=  A8  +  A.ONE  ; 

A10  :  INTEGER  :=  A9  +  A.ONE  ; 

begin 

ITERATION. START.CONTROL  ;  --  dummy  to  bring  in  pages  on  some  mochines 

delay  0.5  ;  --  wait  for  stable  enviornment  on  some  machines 

ITERATION. INITIALIZE  (  ITERATION.COUNT  )  ; 

loop  --  unlit  stable  measurement,  ; • cRATION.COUNT  increoses  each  time 


■■  Control  loop 

ITERATION. START.CONTROL  ; 
for  J  in  1  ..  ITERATION.COUNT  loop 
GLOBAL  :=  0  ; 

for  INSIDE. LOOP  ml..  CHECK. TIMES  loop 

GLOBAL  :=  GIOBAL  *  Al*A2*A3tA4*AS+A6+A7-A8-A9  A10  ; 
REMOTE  ; 
end  loop  ; 
end  loop  ; 

ITERATION. STOP. CONTROL  (  GLOBAL  ,  CHECK. TIMES  ^  ; 


Test  loop 

ITERATION. START. TEST  ; 
for  J  m  1  ..  ITERATION.COUNT  loop 
GLOBAL  :=  0  ; 

for  INSIOE.LOOP  ml..  CHECK.TIMES  loop 

PROC.0  (  Al,  A2.  A3,  A4.  AS,  A6,  A7,  A8,  A9,  A10  )  ; 
-  this  has  control  global  incren."nt  ond  call  inside 
end  loop  ; 
end  loop  ; 

ITERATION. STOP. TEST  (  GLOBAL  ,  CHECK.TIMES  )  ; 

ITERATION. TEST. STABLE  (  ITERATION.COUNT  ,  STABLE  )  ; 
exit  when  STABLE  ; 
end  loop  ; 


ITERATION. FEATURE. times  f  CPU. TIME  ,  WALL. TIME  )  ; 
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--  Printout 

PIWG_IO.PIWG_OUTPUT  C  "P000010"  ,  "Procedure"  , 

CPU.TIME  ,  WALL.HME  ,  ITERATION_COU^:r  , 
"  Procedure  call  and  return  time  measurement"  , 

"  Compare  to  P000005  "  , 

"  10  porameters,  in  INTEGER  "  )  ; 

end  P000010  ; 


with  REMOTE.GLOBAL  ;  use  REMOTE.GLOBAL  ; 
package  body  PROC_PACKAGE_10  is  —  compare  to  P000005 
procedure  PROC_0  C  Al,  A2,  A3,  A4,  AS,  A6,  A7,  A8,  A9,  A10  :  in  INTEGER  )  is 
begin 

GLOBA!  GLOBAL  +  A1+A2+A3+A4+A5+A6+A7-A8-A9-A10  ; 

REMOTE  j 
end  ; 

end  PROC_PACKAGE_10  ; 
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--  PERFORMANCE  MEASUREMENT  :  Minimun  entry  coll  and  return  tii«e 

task  inside  procedure 
1  task  1  entry 
no  select,  do. .end 

with  REMOTE.GLOBAL  ;  use  REMOTE_GLOBAL  ;  —  control  optimization 
with  ITERATION  ;  ---  obtain  stable  measurement 
with  PIWG.IO  ;  --  output  results 

procedure  T000001  is  --  main  procedure  to  execute 

CPU_TIME  :  DURATION  ;  --  CPU  time  for  one  feature  execution 
WALL_TIME  :  DURATION  ;  --  WALL  time  for  one  feature  execution 
CHECK_TIMES  :  constant  :*  100  ;  --  inside  loop  count  and  check 

ITERATION_COUNT  :  ITERATION. ITERATION.COUNTS  ;  —  set  and  varied  by  ITERATION  package 
STABLE  :  BOOLEAN  ;  —  true  when  measurement  stable 


task  T1  is 
entry  El  ; 
end  T1  ; 

task  body  T1  is 
begin 
loop 

accept  El  do 

GLOBAL  GLOBAL  +  A_ONE  ; 

REMOTE  ; 
end  El  ; 
end  loop  ; 
end  ; 

begin 

ITERATION . START.CONTROL  ;  --  dummy  to  bring  in  pages  on  some  machines 

delay  00.5  ;  --  woit  for  stable  enviornment  on  some  machines 

ITERATION. INITIALIZE  (  HERAHON.COUNT  )  ; 

loop  --  until  stable  measurement,  ITERAT10N_C0UNT  increases  each  time 


Control  loop 

ITERAnON.START.CONTROL  ; 
for  J  in  1  ..  ITERATION.COUNT  loop 
GLOBAL  0  ; 

for  INSIDE_LOOP  in  1  . .  CHECK.TIMES  loop 
GLOBAL  :=  GLOBAL  +  A_ONE  ; 

REMOTE  : 
end  loop  ; 
end  loop  ; 

ITERATION.STOP.CONTROL  C  GLOBAL  ,  CHECK.TIMES  )  ; 


--  Test  loop 

ITERATION. START.TEST  ; 
for  J  in  1  ..  HERATION.COUNT  loop 
GLOBAL  0  ; 

for  INSIDE.LOOP  ini..  CHECK.TIMES  loop 
Tl.El  ;  --  this  has  control  global  increment  and  call  inside 
end  loop  ; 
end  loop  ; 

ITERATION. STOP.TEST  (  GLOBAL  ,  CHECK.TIMES  )  ; 
ITERATION.TEST.STABLE  (  ITERATION.COUNT  ,  STABLE  )  ; 
exit  when  STABLE  ; 
end  loop  ; 

ITERATION. FEATURE.TIMES  C  CPU.TIME  ,  WALL.TIME  )  ; 
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—  Printout 

PIWG_I0.PIWG_0UTPUT  C  "1000001"  ,  'Tasking"  , 

CPU.TIME  ,  WALL.TIME  ,  ITERATION.COUHT  , 
"  Mininun  rendezvous,  entry  call  and  return  tine  "  , 

"  1  task  1  entry  ,  task  inside  procedure  "  , 

"  no  select  "  )  ; 

abort  T1  ; 

end  T000001  ; 
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—  PERFORMANCE  MEASUREMENT  :  tasks  entry  coll  and  return  time 

1  task  2  entries 
one  select  statement 

with  REMOTE.GLOBAL  ;  use  REMOTE.GLOBAL  ; 
package  TASK_PACK_4  is 
task  T1  is 
entry  El  ; 
entry  E2  ; 
end  T1  ; 

end  TASK_PACK_4  ; 

with  TASK_PACK_4  ;  use  TASK_PACK_4  ; 

with  REMOTE_GLOBAL  ;  use  REMOTE.GLOBAL  ;  --  control  optimization 
with  ITERATION  ;  --  obtain  stable  measurement 
with  PIWG_IO  ;  --  output  results 

procedure  T000004  is  --  main  procedure  to  execute 
CPU_TIME  :  DURATION  ;  --  CPU  time  for  one  feature  execution 
WALL_TIME  :  DURATION  ;  --  WALL  time  for  one  feature  execution 
CHECK_TTMES  :  constant  :=■  100  ;  --  inside  loop  count  and  check 

ITERATION_COUNT  :  HERATION.ITERATION.COUNTS  ;  —  set  end  varied  by  ITERATION  package 
STABLE  :  BOOLEAN  ;  —  true  when  measurement  stable 
CASE_COUNT  :  constant  :=  2  ; 

begin 

ITERATION. START_C0NTR0L  ;  --  dummy  to  bring  in  poges  on  some  machines 

delay  0.5  ;  --  wait  for  stable  enviornment  on  some  machines 

ITERATION. INITIALIZE  C  ITERAHON.COUNT  )  ; 

loop  --  until  stable  measurement,  ITERATION- COUNT  increoses  each  time 


--  Control  loop 

HERAHON. START-CONTROL  ; 
for  J  in  1  ..  ITERAHON-COUNT  loop 
GLOBAL  0  ; 

for  INSIDE-LOOP  in  1  . .  CHECK-TIMES  loop 
GLOBAL  GLOBAL  +  A-ONE  ; 

REMOTE  ; 
end  loop  ; 
end  loop  ; 

ITERATION. STOP-CONTROL  C  GLOBAL  ,  CHECK-TIMES  )  ; 


--  Test  loop 

ITERATION. START-TEST  ; 
for  1  in  1  ..  HERATION-COUHT  loop 
GLOBAL  :>  0  ; 

for  INSIDE-LOOP  in  1  . .  CHECK-TIMES  loop 
Tl.El  ;  --  this  has  control  global  increment  and  call  inside 
T1.E2  ;  --  this  has  control  global  increment  and  call  inside 
end  loop  ; 
end  loop  ; 

GLOBAL  :=.  GLOBAL  /  CASE-COUNT  ; 

ITERATION. STOP-TEST  (  GLOBAL  ,  CHECK-HMES  )  ; 

ITERATION. TEST-STABLE  C  ITERATION-COUNT  ,  STABLE  )  ; 
exit  when  STABLE  ; 
end  loop  ; 

ITERATION. FEATURE-TIMES  (  CPU-TIME  ,  WALL-TIME  )  ; 

CPU-TIME  DURATION  C  CPU-TIME  /  CASE-COUNT  )  ; 

WALL-TIME  OURATION  C  WALL-TIME  /  CASE-COUNT  )  ; 
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--  Printout 

PIWG_IO.PIWG_OUTPUT  C  "T000004"  ,  "Tasking"  , 

CPU.TIME  ,  WALL.TIME  .  ITERATION.COUNT  , 
"  Tosk  entry  call  and  return  time  measured"  , 

"  One  tasks  active,  two  entries,  tasks  in  a  package  "  , 

"  using  select  statement  "  )  ; 

abort  T1  ; 
end  TOeoeOA  ; 

package  body  TASK_PACK_4  is 
task  body  T1  is 
begin 
loop 
select 

accept  El  do 

GLOBAL  GLOBAL  -f-  A_ONE  ; 

REMOTE  : 
end  El  ; 
or 

accept  E2  do 

GLOBAL  :=  GLOBAL  +  A_ONE  ; 

REMOTE  ; 
end  E2  ; 
end  select  ; 
end  loop  ; 
end  T1  ; 

end  TASK_PACK_4  ; 


Appendix  C 


Selected  DIANA  Representations  of  Test  Programs 


The  timed  fragment  from  POOOOOl  and  the  entirety  of  SimpleTasks  is 
included  here  in  DIANA  form.  This  DIANA  form  is  that  used  on  the  Rational 


machine.  It  represents  as  a  bracketed  list  with  a  node  type  tag,  non- 
structural  attributes,  and  child  nodes  (structural  attributes)  in  that  order. 


e.g.,  [dn_type  attrl  attr2  [childl]  [child2]].  The  hexadecimal  numbers  to  the 
left  are  memory  addresses  for  the  nodes  and  can  be  ignored.  Semantic 
attributes  of  the  form  sm_attr  =  [dn_tag  ''I  represent  a  pointer  to  a  specific 


existing  node  of  the  type  indicated. 


POOOOOl: 

1FC910A_10C7B; 

1FC910A_10E82: 

1FC910A_10EFB: 


1FC910A_1101B; 

1FC910A_110B7: 


1FC910A_11136: 


1FC910A_UFE1: 


[ON.LOOP 

lx_line_count  =  7 

[ON_FOR 

[DN_ITERAnON_ID 
SM.SEQNUM  *  1 
SM_PARENT  =  [DN_PR0C_ID 
lx_syrarep  -  "J" 
sni_obj_type  =  [DN_RANGE  ■'] 

] 

[DN_RANGE 

sm.base.type  =  [DN_INTEGER 
[DN_NUMERIC_LITERAL 
Ix.niimrep  =  "1" 
siii_exp_type  =  [DN.INTEGER  a] 
sni_ value  ^  1 

] 

[DN_USED_OBJECT_IO 

Ix.symrep  =  "ITERATION_COUNT" 
sra_defn  =  [DN_VAR_ID  a] 
sm_exp_type  =  [DN.CONSTRAINED  a] 
sm_value  =  No  value 

] 

] 

] 

[0«_STM_S 

lx_line_count  =  5 


93 


1FC910A_111F3: 


1FC910A_1127O: 


1FC910A_U31F; 


1FC910A_113B9: 

1FC910A_115C0: 

1FC910A_11639: 


1FC910A_11759: 

1FC910A_117F5: 


1FC910A_11874: 


1FC910A_11F71: 

1FC910A_11931: 

1FC910A_119BB: 


1FC910A_11A5D: 


1FC910A_11B1C: 


1FC910A_11D7D: 

1FC910A_11BCF: 


1FC910A_11CA6: 
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[ON_ASSIGN 

lx_Une_count  =  1 

[DN_USED_06JEa_ID 

lx_syiirep  =  "GLOBAL” 
siii_defn  -  [DN_VAR_ID  a] 
siii_exp_type  «  [DN_CONSTRAINED 
siii_value  ■>  Uninitialized 

] 

[DN_MUMERIC_LITERAL 
lx_nunirep  =  "0" 
sm_exp_type  =.  [DN_INTEGER  a] 
siii_value  0 

1 

] 

[ON.LOOP 

lx_line_count  =  4 

[DN_F0R 

[DN_nERATION_ID 
SM_SEQNUM  =  1 
SM_PARENT  =  [DN_PROC_ID 
lx_syiiirep  =  ”INSIDE_LOOP" 
siii_obj_type  =  [DN.RANGE  *] 

1 

[DN_RANGE 

sm_base_type  =  [DN_INTEGER 
[DN_NUMERIC_LITERAL 
lx_nunirep  =  "1" 
siii_exp_type  =  [DN.INTEGER  a] 
sn_value  =  1 

] 

[DN_USED_OBJECT_ID 

lx_syi«rep  =  "CHECK.TIMES" 
sm_defn  =  [DN_NUMBER_ID  a] 
sm_exp_type  =  [DN_INTEGER  a] 
siii_value  =  100 

] 

] 

] 

[DN.STM_S 

lx_line_count  •  2 
[DNJiSSIGN 

lx_line_count  =  1 
[DN_USED_OBJECT_ID 

lx_symrep  =  "GLOBAL" 
sm_defn  =  [DN_VAR_ID  a] 
sm.exp.type  -  [DN_CONSTRAlNEO  a] 
siii_value  =  Uninitiolized 

] 

[DN_FUNCTION_CALL 

sm.exp.type  =  [DN_INTEGER  a] 
sm.volue  =  Uninitiolized 
sm_nori»Qlized_poram_s  =  [DM_EXP_S  a] 
lx.ppefix  I-  FALSE 
[DN_USED_BLTH_OP 

SM_ORIGINAL_NODE  =  [DN_USEO_OP  a] 
Ix.symrep  =  "+" 
sd.operator  "  IMTEGER_ADD 

] 

[DN_PARAM_ASSOC_S 

[DN_USED_OBJECT_ID 
lx_syiiirep  =  "GLOBAL" 
sm_defn  =  [0N_VAR_ID  a] 
siii_exp_type  =  [DN.CONSTRAINED  a] 
sm_value  *  Uninitialized 

] 

[DN_USED_OBJECT_ID 
Ix.symrep  =  "A_0NE" 
sm_defn  =  [DN_VAR_ID  a] 
sm_exp_type  =  [DN.CONSTRAINED  a] 
sm  value  *  Uninitialized 

] 

] 

] 
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XFC910A_11DF7: 

1FC910A_11E9B: 


1FC910A_11F12: 


[DN_PROCEDURE_CAlL 
lx_Une_count  =  1 

sm_norgKilized_paraii_s  =  [DN_EXP_S  ''J 
[ON_USED_NAME_ID 

Ix.symrep  =  "REMOTE" 
suLdefn  =  [DN_PROC_ID 

] 

[DN_PARAM_ASSOC_S] 
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SimpleTasks: 


1F77D0AJ«)12: 


1F77D0A.CE56: 


1F77D0A.CEC6: 


1F77D0A_CF6A: 


1F77O0A_I»AC: 

lF77t»ft_D10B: 


1F77D0A_D19B: 

1F77D0A.13D74: 

1F77D0A.D25A: 

1F77D0A_DS54; 

1F77D0A.D2FE: 


1F77D0A.D429: 


1F77O0A,O583; 

1F77O0A_D695: 

1F77O0A.D70C; 

1F77O0A.O7A6: 

lF77t»A_()975: 

1F77D0A_D84A: 


1F77D0A_D9O4: 


1F77D0A.DAB6: 


lF77C)eA_DB2D: 


1F77D0A_DC0A: 


[DN.COMP.UNIT 

lx.line.count  •  55 
SM.ID_TABLE  - 
[DN.COHTEXT 

lx_line_count  -  0 

] 

[[)N_SUBPROGRAM_BOOY 

SH_FO(»IARO  -  [Otl.SUBPROGRAM.DECL 
lx_line.count  -  55 
[DN.PROC.ID 

DO.TRUST.ME  -  2 
lx.syiiirep  -  'DOIT" 
snuspec  -  [ON.PROCEDURE  a] 
sni.body  -  [DN.BLOCK  x] 
snustub  -  null 
sin.fi  rst  -  [DN.PROC.ID  x] 

] 

[DN.PROCEDURE 

[DN.PARAM.S 

lx.line.count  -  0 
SM.IO.TABLE  - 

] 

] 

[DN.BLOCK 

POST.COMMENT.HEIGHT  -  -2 
PRE.CO»«MT.HEIGKT  -  -2 
lx.line.count  •  53 
[DN.ITEM.S 

lx.line.count  -  49 
[DN.VAR 

lx.line.count  -  1 
[DN.1D.S 

[DN.VAR.IO 

SM.PAREMT  -  [DN.PROC.ID  x] 

Ix.symrep  »  “ COUNT Ji" 
sm.obj.type  -  [DN.CONSTRAINEO  x] 
sm_obj.def  -  [DN.NUMERIC.LITERAL  x] 

] 

[ON.VAR_IO 

SM.PARENT  .  [DN.PROC.ID  x] 
lx.symrep  -  "COUNT.B” 
sm.ob].type  -  [DN.CONSTRAINEO  x] 
sm.obi.def  -  [DN.NUMERIC.LITERAL  x] 

] 

[DN.CONSTRAINEO 

sm.type.struct  •  [ON.INTEGER  x] 
sm.base.type  -  [ON.INTECER  x] 
sm.constraint  -  [ON.RANGE  xj 
[ON.USEO.NAME.IO 

lx.symrep  •  "INTEGER" 
sm.defn  -  [ON.TYPE.ID  x] 

] 

[DN.VOID] 

] 

[DN.NUMERIC.LITERAL 
lx.numrep  -  "0" 
siti.exF_type  -  [ON.INTEGER  x] 
sm. value  -  0 

] 

] 

[DN.VAR 

POST.COtWENT.HEIGHT  -  -2 
lx.line.count  -  2 
[DN.ID.S 

[DN.VAR.IO 

SM.PAREMT  -  [DN.PROC.ID  x] 
lx.symrep  -  "RESULT.C” 
sm.obj  type  -  [DN.CONSTRAINEO  x] 
sm.obj.def  -  [DN.NUMERIC.LITERAL  x] 

] 

] 

[DN.CONSTRAINEO 

sm.type.struct  -  [ON.INTEGER  x] 
sm.base.type  -  [ON.INTEGER  x] 
sm.constraint  •  [DN.RANGE  x] 
[ON.USEO.NAME.IO 

lx.symrep  •  "INTEGER" 
sm.defn  .  [DN.TYPE.ID  x] 

] 

[DN.VOID] 

] 

[DN.NUMERIC.LITERAL 
lx.nunrep  -  "6" 
sm.exp.type  -  [ON.INTEGER  x] 
sm.value  -  6 

] 

] 

[DN.TASK.DECL 

POST.COMMENT.MEIGtrr  .  -2 
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1F77D0A.DC94: 


1F77IMA_008A: 

lF770eA_D£lD; 


lF77t»A_DF3F; 

1F770«A_DFC9: 


1F77D0A_E06F : 
1F77D0A_E152: 


1F77D0A.E274; 

1F77O0A_E2FE: 


1F77O0A_E3F4; 

lF77Oav_EOC0: 

1F77O0A.E487; 

1F770W_E52B: 


1F77D0A.E64B: 

1F77D0A.E6O5: 


1F77D0A_E79A; 
1F77D0A.E83E . 


1F77D0A_E95E : 
1F77D0A_E9E8: 


1F77O04.EAAD: 

1F77D0A_EB51: 


lx.line.count  -  3 
[0N.VAH_ID 

SH.PARE((T  -  [OH.PROC.ID  '>] 

1x_s>mrep  •  "TASK.A" 
sm_ob].type  -  [ON.TASIC_SI>£C  *] 
siii_ob].deF  -  [DN.TASK.SPEC  *] 

] 

[ON.TASK_SPEC 

lx_Un«_count  •  0 
sni.body  -  [ON.BLOCH  a] 

[WI.0eCL.S 

LX_VEHBOSE  -  TRUE 
lx_lin*_count  -  0 
SM.ID.TABLe  - 

] 

] 

] 

[DN_TASK.O€CL 

POST.COWCMT.HEIGHT  -  -2 
lx_Une_£Ount  •  3 
[DN.VAR_ID 

StCPARENT  -  [ON.PROC.IO 
Ix.synrep  -  ■TASK_B“ 

»-Ob].type  -  fWI.TASK.SPEC  a] 
siii_obj.def  -  [WI.TASK.SPEC  a] 

] 

[WI.TASK.SPEC 

lx.lin«.ccKint  •  0 
sm.body  -  [DN.BLOCK  a] 

[DN.OECL.S 

LX.VER80SE  -  TRUE 
lx.line.count  •  0 
SH.IO.TABLE  - 

] 

] 

] 

[DN.TASK.DECL 

POST.COUCNT.HEIGHT  -  -2 
lx.line.count  -  6 
[ON.VAR.ID 

SM.PARENT  -  [ON.PROC.IO  a] 

Ix.synrep  -  "TASK.C" 
sm.obj.type  •  [OH.TASK.SPEC  a] 
sm.ob].def  -  [DN.TASK.SPEC  a] 

] 

[ON.TASK.SPEC 

lx.line.count  •  0 
sm_body  -  [ON.BCOCK  a] 

[OH.DECL.S 

lx.line.count  -  3 
[0N.SU8PR0GRAM.0CCL 
lx.line.count  •  1 
[ON.ENTRY_ID 

SM.SEQNUM  -  1 
SM.PAREMT  -  [DN.VAR.ID  a] 
lx  sjBirep  -  "ENTRYJi" 
si».spec  -  [DN.ENTRY  a] 

] 

[DN.ENTRY 

lx.line.count  -  0 
[ON.VOID] 

[DN.PARAM.S 

Ix.li'''’  '•nunt  -  0 
SM.ID.TABLE  - 

] 

] 

[ON.VOID] 

] 

[ON.SUBPROGRAM.DECL 
lx.line.count  -  1 
[DN.ENTRY.IO 

SM  SEQNUM  -  2 
SM.PAREMT  -  [DN.VAR.ID  a] 
Ix.symrep  -  "ENTRY.B" 
sm.spec  -  [DN.ENTRY  a] 

] 

[DN.ENTRY 

lx.line.count  -  0 
[ON.VOID] 

[DN.PARAM.S 

lx.line.count  •  0 
SM.ID.TABLE  - 

] 

] 

[DN.VOIO] 

] 

[ON.SUBPROGRAM.DECL 
lx.line.count  •  1 
[DN.ENTRY.IO 

SM.SEQNUM  -  3 
SM.PARENt  .  [DN.VAR.ID  *] 
Ix.symrep  ■  'DONE’ 
sra  spec  -  [DN.ENTRY  a] 

] 


1F7709A.EC71: 

lF770e*.'CEB: 


1F77D0A.F14A: 

1F770W.F1M: 

1F77D«*_F2C3: 

1F77D0A_F367: 

lF77Da»_106£3: 

1F77I»A.F412: 

1F77O0A.F619: 

1F770M-F69e; 


1F7708A.F7B2: 
1F77O0A.F84E : 

1F770«A.F8CD: 


1F77D0A.FE62: 
1F77O0*_F9O*: 
IF  7708*  .F  464  ■, 

lF770e*.FBe6: 

1F77D8A.FBC5: 

1F77O0A_FE03: 

1F77D0A_FC78: 

1F7708A.FD4F: 


[W.ENTRY 

l*_Uoe_count  -  8 
[08.VOID] 

[DN_P*11AM_S 

lx.line.count  -  0 
S«_ID_TABLE  - 

] 

•y 

[DN.VOIO] 


[ON.TAStC.BOOY 

SM.FOWARD  -  [ON.TASK.OECL  *] 
lx_l ine.count  -  9 
[DN.TASK.BOOY.ID 

Ix.symrep  •  •TASK_A" 
sm.spec  -  [DN.TASK.SPEC  x] 
s«.body  -  [DN.BLOCK  x] 
sm.stub  -  null 
sm.first  -  [DN.VAR.ID  x] 

] 

[DN.BLOCR 

POST.CO*8€NT.H£ICHT  -  -2 
lx.line.count  •  8 
[ON.ITEM.S 

lx_line_count  -  8 
SM.IO.TABLE  - 

] 

[0N.STM_S 

lx_line_count  •  6 
[ON.LOOP 

lx.Une.coont  -  3 
[DN_F0fi 

[D«_ITERATI0N.ID 
SM_SEQNUM  -  1 


SM.PARERT  -  [DN_VAR_ID  x] 
lx.symrep  -  "I* 
siii.obj.type  -  [DN.RANGE  x] 

] 

[OR.RAHtE 

SBt.bose.type  -  [ON.INTECER  x] 
tOW.MUMERIC.LITERAL 
lx.numrep  •  '1* 

SBi.exp.type  •  [DN.INTEOER  x] 
SBi.volue  -  1 

1 

[ON.NUMERIC.LITERAL 
SM.INT.VALUE  -  1080 
lx_nuiipep  -  •1000" 

SBi.exp  type  •  [DN.INTECER  x] 
SBi.volue  -  1000 


[ON.STM.S 

lx.Une.count  -  1 
[ORJISSICN 

lx.Une.count  -  1 
[0H.USED.063ECT.ID 

lx.symrep  •  "  COUNT  Jl" 

SBi.defn  .  [DN.VAR.ID  x] 

SBi.exp.type  -  [ON. CONSTRAINED  x] 

SBi.volue  -  Uninitialized 

] 

[DN.FUNCTION.CALL 

SBi.exp.type  •  [DN.INTECER  x] 

SBi.volue  -  Uninitiol ized 
SBi.normolized.poron.s  -  [DN.EXP.S  x] 
Ix.prefix  -  FALSE 
[DN.USED.BLTN.OP 

SM.ORIGINAL.NOOE  -  [DN.USED.OP  x] 

lx.symrep  - 

SBi.operotor  -  INTEGERJVDO 

] 

[DN.PARANJISSOC.S 

[ON.USED.OBJECT.ID 

lx.symrep  -  "COUNTJl" 

SBi.defn  .  [DN.VAR.ID 
SBi.exp.type  -  [DN.CONSTRAINEO  x] 
SBi.volue  -  Uninitialized 

] 

[DN.NUMERIC^LITERAL 
Ix.niinrcp  «  "I" 
sm.exp.typc  -  [DN.INTEGER 
sm.volue  -  1 


[DN.ENTRY.CALL 


1F77O0A.FEO2: 


1F77D0A.FF76: 

1F77D0A.100U: 


lF77D0A_100eC: 


1F77D0A_10133; 

1F77D0A_10Z38: 

lr77O0A.102C2? 


1F77O0A.10364: 


1F77D0A.10423: 


1F77D0A_10684: 
IF  7700*. 104 06: 


IF77O0A_105AO: 


1F77O0A_10753: 


1F77O0A.10891: 

1F77D0A_1091B: 


1F77O0A_10A0A: 
1F77O0A_10AAE : 

1F77O0A.11DOA: 

1F77O0A.10B59: 

1F77D0A_10O60: 

1F77D0A.10DO9: 


1F77D0A.10EF9: 

1F77D0A.10F95: 
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SM_OR1GINAL.NOOE  -  [0N_PR0CE0URE_CALL 
lx_line_count  -  1 

Sffl_nomalized.param_s  -  [DN.EXP.S  a] 
[OK.StlEaED 

snuexp.type  -  null 
sffl.value  ••  Uninitialized 
C0N.USE0.0ejECT.I0 

lx_s>mrep  -  "TASK.C" 
sm_defn  -  [ON.VAR_IO  *] 
sm.exp.type  -  [l»_TASK.SPEC  *] 
sm_value  -  Uninitialized 

] 

[DR.USED.NAHE.IO 

Ix.symrep  •  "ENTRYJi" 
sm_defn  -  [ON.ERTRY.IO  *] 

] 

[ON_PARAHJiSSOC.S] 

] 

[ONJiSSIGH 

lx.line.count  -  1 
[ON  OSEO.oejECT.IO 

Ix.symrep  -  "COURTJi" 

Si!i.defn  -  [DN.VAR.IO  n] 
sm_exp_type  -  [ON.CONSTRAINEO  *] 
sm.value  •  Uninitialized 

] 

[ON.FUNCTION.CALL 

sm.exp_type  -  [DN.INTECER  *] 
sni-volue  -  Uninitialized 
sm_normalized_par£iii_s  -  [DN.EXP.S  n] 
lx_prefix  -  FALSE 
[DN.USED.BLTN.OP 

SM.ORIGINAL.NOOE  -  [DN.USED.OP  n] 
Ix.symrep  -  '+" 
sm.operator  •  INTEGERJiDD 

] 

[ON.PARAMJiSSOC.S 

[ON.USED.OBJECT.ID 

Ix.symrep  -  "COUNTJi" 
sm.defn  -  [DN.VAR.IO 
sm.exp.type  -  [DN.CONSTRAINEO  *] 
sm.volue  -  Uninitialized 

] 

[ON.USED.OBJECT.ID 

Ix.symrep  -  "COUNTJi" 
sm.defn  .  [DN.VAR.IO  <>] 
sm.exp.type  -  [DN.CONSTRAINEO  '‘3 
sm_ value  •  Uninitialized 

] 


[DNJiLTERNATIVE.S 

lx.line.count  -  0 

] 

] 

] 

[DN.TASK.BOOY 

SM.FORNARD  -  [DN.TASX.DECL  n] 
lx.line.count  -  9 
[DN.TASK.BOOY.IO 

Ix.symrep  -  "TASK.B" 
sm.spec  -  [DH.TASX.SPEC  n] 
sm.body  -  [DN.BLOCX  n] 
sm.stub  -  null 
sm.fi rst  -  [DN.VAR.IO  *] 

] 

[DN.BLOCK 

POST.COtWENT.HEICHT  -  -2 
lx.line.count  •  8 
[ON.ITEH.S 

lx.line.count  -  0 
SN.ID.TABLE  - 

] 

[0N.STH.S 

lx.line.count  -  6 
[ON.LOOP 

lx.line.count  -  3 
[ON.FOR 

[ON.ITERATION.ID 
SM.SEQNUM  -  1 
SM.PARENT  .  [DN.VAR.IO  r] 
Ix.symrep  -  "I" 
sm.obj.type  -  [DN.RANGE  '  i 

] 

[DN.RANGF 

sw.base.type  •  CW.INTEGER 
[DN.NUMERIC^LITERAL 
lx_numrep  •  "1" 
sm.exp.type  -  [DN.IffTEGER 
sm  volue  -  1 

] 


1F77D0A_11014: 


1F77O0A_11559; 

1F77D0A.110AE: 

1F77D0A_11138: 


1F77D0A_1UD4: 

1F77D0A_11299: 

1F77D0A_114FA; 

1F77D0A_1134C: 


1F77D0A_11423; 

1F77D0A.115C9; 

1F77O0A_1166D: 

1F77D0A.11711: 

1F77D0A_117B3: 

1F77D0A_1182A: 
1F77D0A_1192F : 
1F77D0A_119B9: 

1F77D0A.11A5B: 

1F77D0A_11B1A: 

1F77D0A_11D7B: 

1F77D0A.11BCD: 


1F77D0A.11CA4: 


100 

[DN.NUMERIC.LITERAL 
lx.nunrep  -  “100" 
siii_exp_type  -  [ON.INTEGER  *] 

Sffl_value  -  100 

] 

] 

] 

[DN_STM_S 

lx_line_count  -  1 
[DN_ASS1GN 

lx_line_ccxjnt  -  1 
[DN.USED_OBJEa_ID 

lx_symrep  -  "COUNT.B" 
siii_defn  -  [0N_VAR_ID 
siii_exp_type  -  [DN.CONSTRAINED 
sm_value  -  Uninitialized 

] 

[DN_FUNaiON.CALL 

sm_exp_type  -  [DN_INTEGER 
sin_value  -  Uninitialized 
sm_nornialized_param_s  »  CDN_EXP_S 
lx_prefix  -  FALSE 
[DN_USED_BLTN_OP 

SM_0RIGINAL_N00E  -  [DN.USED.OP  *] 
lx_sympep  -  "+" 
snuoperator  -  INTEGERJiDO 

] 

[ON.PARAMJiSSOC.S 

[DN.USED.OBJECT_ID 

lx_symrep  »  "COUNT.B" 
sm.defn  -  [DN_VAR_ID  *] 
sm_exp_type  -  [DN_CONSTRAINED  a] 
sm_value  -  Uninitialized 

] 

[DN_USED_OBJECT.IO 
lx_symrep  -  "I" 
sm_defn  -  [DN.ITERATION_ID  *] 
sm.exp.type  -  [DN_RANGE 
sni.value  -  Uninitialized 

] 

] 

] 

] 

] 

] 

[DN.ENTRY.CALL 

SM_ORIGINAL.NODE  -  [DN.PROCEDURE.CALL  a] 
lx.line-count  -  1 

sm.normalized_param_s  -  [DN.EXP.S  ''] 

[DN.SELEaED 

sm_exp.type  -  null 

sm_ value  •  Uninitialized 

[DN_USED_OBJECT.ID 

Ix.symrep  -  "TASK.C” 
aii_defn  -  [DN.VAR.ID  *] 
sm_exp_type  -  [DN_TASK_SPEC 
an. value  -  Uninitialized 

] 

[DN.USEO.NAME.ID 

lx.symrep  -  "ENTRY_B" 
sm.defn  -  [DN_ENTRY_ID 

3 

] 

[DN.PARAMJiSSOC.S] 

3 

[ONJiSSIGN 

lx_line_count  •  1 
[DN.USED_OBJECT_ID 

lx  symrep  -  "C0UNT_B" 
sm.defn  -  [DN.VAR.ID  a] 
sm.exp.type  -  [DN.CONSTRAINED  ''] 
sm.value  -  Uninitialized 

3 

[ON.FUNCTION.CALL 

sm.exp.type  -  [DN.INTEGER 
sm.value  -  Uninitialized 
sm_normalized.par(in.s  -  [DN.EXP.S 
lx.prefix  -  FALSE 
[DN.USED.BLTN.OP 

SM.ORIGINAL.NODE  -  [DN.USED.OP  -i] 
lx.symrep  -  "+" 
sm.operator  -  INTEGERJiDD 
3 

[DN.PARAMJVS50C.S 

[DN.USED.OBJECT.ID 

lx.symrep  -  "COUNT.B" 
sm.defn  -  [DN.VAR.ID  *] 
sm.exp.type  -  [DN.CONSTRAINED  *] 
sm.value  -  Uninitialized 

3 

[DN.USED.OBJECT.ID 

lx.symrep  -  "COUNT.B” 
sm.defn  -  [DN.VAR.ID  ''] 
sm.exp.type  -  [DN.CONSTRAINED  a] 


1F77D0A_11E4A: 

1F77D0A_11F88: 

1F77()0A_12012; 

1F77D0A_12101: 

1F77D0A_121A5: 

1F77[)0A_13BC6; 

1F77D0A_12250; 

1F77O0A.12457; 

1F77D0A_124O0: 


1F77D0A_125F0: 

1F77D0A.1268C: 

1F77O0A.1270B: 


1F77D0A_13920: 

1F77O0A.1278A: 

1F77D0A.1380B: 

1F77D0A_1282F: 

1F77O0A_12F92: 

1F77O0A.128O4: 

1F77D0A_12978: 

1F77[)0A_129£F: 

1F77D0A_12F22: 

1F77D0A_12A9A: 

1F77D0A_12B24: 

1F77D0A.12BC6: 

1F77D0A_12C85: 


Uninitialized 


[DNJiLTERNATIVE.S 
lx_line_count  - 


[DN.TASK.BODY 

SM_FORWARD  -  [DN.TASK_OECL 
lx_line_count  -  16 
[DN_TASK_B00Y.ID 

lx_s>mrep  -  “TASK_C" 
siiLspec  -  [DN_TASK.SPEC  n] 
sm_body  -  [DN.BLOCK  *;] 
sffl_stub  -  null 
sm_first  -  C0N_VAR_I0 

] 

[DN.BLOCK 

POST.COFMENT.HEIGHT  -  -2 
lx_Une_count  •  15 
[DN.ITEM.S 

lx_Une_count  -  0 
SM.ID_TABLE  - 

] 

[DN.STM.S 

tx_line_count  -  13 
[DN.LOOP 

lx_Une.count  -  11 
[ON.FOR 

(T)N.ITERATI0N_ID 
SM.SEQNUM  -  1 


SM.PARENT  -  [DN.VAR_ID  a] 
Ix.symrep  -  "I" 
sin_obj_type  -  [DN.RANGE  *] 

] 

[DN_RANGE 

sm_base_type  -  [DN.IMTEGER  a] 
[ON.NUHERIC.LITERAL 
Ix.ntmrep  •  "1" 
sm_exp_type  -  [DN.IRTEGER  *] 
sill. value  -  1 

] 

[ON.NUMERIC.LITERAL 
Ix.nimrep  ■  "2” 
sni.exp_type  -  [DN.INTEGER 
stti_volue  -  2 


tON_STH,S 

lx  line_count  •  9 
[DN,SELECT 

lx_line_count  -  9 
[DN.SELECT.CLAUSE.S 
lx_line_count  -  8 
[DN.SELECT.CUUSE 
lx_Une_count  -  3 
[DN.VOID] 

[DN.STM.S 

Ix.line.count  •  3 
[DNJiCCEPT 

Ix.line.count  -  3 
[DN.USED.NAME.IO 

lx.symrep  -  "ENTRYJi" 
sm.defn  -  [DN.ENTRY.ID  *] 

] 

[DN.PARAM.S 

Ix.line.count  -  0 
SM.ID.TABLE  - 

] 

[DN.STM.S 

Ix.line.count  -  1 
[DNJiSSIGN 

lx.line.count  -  1 
[DN.USED.OBJEa.ID 

lx.symrep  -  "RESULT.C" 
sm.defn  •  [DN.VAR.ID  n] 

Sffl.exp.type  -  [DN.CONSTRAINED  <'] 
siii.value  -  Uninitialized 

] 

[DN.FUNCTION.CALL 

Sffl.exp.type  -  [DN.INTEGER  n] 
sffl.volue  •  Uninitialized 
sffl.normalized.paroffl.s  -  [DN.EXP.S  *] 
Ix.prefix  -  FALSE 
[DN.USEO.BLTN.OP 

SM.ORIGINAL.NOOE  -  [DN.USED.OP  x] 
lx.symrep  «  "/" 
sm.operator  -  INTEGER.DIV 


] 
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1F77D0A_12EC3: 

1F77D0A.12D38: 

1F77D0A_12E0F: 


1F77D0A_1301D; 

1F77D0A_13780; 

1F77O0A_130C2; 

1F77D0A.13166: 

1F77D0A_131DD: 

1F77O0A_13710: 

1F77D0A_13288: 

1F77D0A_13312: 

1F77D0A.133B4: 

1F77D0A.13473: 

1F77D0A.136B1: 

1F77O0A_13526: 

1F77D0A_135FO: 


1F77D0A.1387B: 

1F77D0A.139AB: 

1F77D0A_13A4F: 

1F77D0A_13AC6: 

1F77O0A.13B56: 


[DN_PARAMJVSSOC_S 

[DN.USED_OBJEa_ID 

lx_symrep  -  "RESULT.C" 
sm.defn  -  [DN_VAR_ID  *] 
sm_exp_type  -  [DN_CONSTRAINED 
sni_valu«  «  Uninitialized 

] 

[ON.NUMERIC.LITERAL 
Ix.numrep  -  ”2" 
sm_exp_type  -  [DN.INTEGER  *] 
sm_value  -  2 

] 

] 

] 

] 

] 

] 

] 

] 

[ON_SELECT.CLAUSE 
lx_line_count  -  3 
[DN.VOIO] 

[DN.STX.S 

lx_line_count  -  3 
CON_ACCEPT 

lx_line_count  -  3 
[DN.USED_NAME_IO 

lx.symrep  -  ”ENTRY_B" 
sm_defn  -  [DN.ENTRY.ID  *] 

] 

[DN.PARAM_S 

lx_line_count  -  0 
SM_ID_TABLE  - 

] 

[DN_STM_S 

lx_line_count  -  1 


[DNJiSSIGN 

lx_line.count  -  1 
[DN.USED.OBJECT.ID 

lx.symrep  -  "RESULT.C" 
sm_defn  .  [DN_VAR.ID  *] 
sm_exp.type  -  [ON.CONSTRAINED  *] 
sm_valije  •  Uninitialized 

] 

[DN_FUNCTION_CALL 

sm_exp.type  -  [DN.IMTEGER  *] 
sm_vaiue  -  Uninitialized 
sm_nonnaUzed_param_s  ■  [DN.EXP.S  x] 
Ix.prefix  -  FALSE 
[ON.USED_BLTN_OP 

SM.0RIGINAL_N00E  -  [DN.USED.OP  x] 
Ix.symrep  -  "+' 
sm_operator  -  IMTEGER_ADD 

] 

[DN.PARAMJiSSOC.S 

[DN_USEO.OBJECT_ID 

Ix.symrep  -  "RESULT.C" 
sm_defn  -  [DN_VAR_ID  x] 
sm.exp.type  -  [DN.CONSTRAINED  x] 
sm_value  -  Uninitialized 


] 

] 

[ON_STM.S 

lx_line_count  »  0 


] 

[DN.NUMERIC_LITERAL 
Ix.numrep  -  "4" 
sm.exp.type  -  [DN.INTEGER  x] 
sm.volue  -  4 

] 


] 

] 

] 

] 

[DNJiCCEPT 

lx_line_count  -  1 
[ON.USEO.NAME.IO 

lx  symrep  -  "DONE" 
sm  defn  -  [DN.ERTRY.IO  x] 

] 

[0N_PARAH.S 

lx  line.count  -  0 
S«_ID_TABLE  - 

] 

[0N_ST»t.S 

lx_line_c(xjnt  -  0 


] 

] 
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1F77O0A_13C36: 

1F77D0A_1463D: 

1F77D0A.142F2; 

1F77D0A_14396: 

lF77DeA.1443A: 

1F77D0A.144DC: 

1F77D0A_14553: 

1F77D0A_146F0: 

1F77D0A_1483C; 


] 

[DN_ALTERNATIVE-S 

lx_line_count  ■  0 

] 

] 

] 

] 

[DN_STM_S 

PRE_COHMENT_HEIGHT  -  1 
lx_Une_count  -  2 
[DN_EMTRY_CALL 

SM_0RIGINAL_N0D£  -  [DN_PROCEDURE.CALL  *] 
lx_line_count  -  1 

sm_normalized_paraii_s  -  [DN_EXP_S  *] 
CDN.se  LEaED 

sm_exp_type  -  null 
sin_value  -  Uninitialized 
[DN.USED.OBJEa.IO 

lx_sviiirep  -  "TASK.C" 
sm.defn  -  [ON.VAR.ID  *•'] 
sni_exp.type  -  [DN_TASK_SPEC  *] 
siii.value  -  Uninitialized 

] 

[DN_USED.NAME.IO 

lx.symrep  -  "DONE" 
sm.defn  -  [ON.ENTRY.ID 

] 

] 

[DN.PARAMJiSSOC.S] 

] 

] 

[ONJiLTERNATIVE.S 
lx.line.count  -  0 

] 

] 

] 

[DN.PRAGMA.S 

lx.line.count  -  0 

] 


Appendix  D 


Experiment  Output 


main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 
main 

1000  Iterations  of  simple  tasking  system 


takes 

11.8167  seconds. 

takes 

11.9333  seconds. 

takes 

11.9833  seconds. 

takes 

12.0500  seconds. 

takes 

14.3834  seconds. 

takes 

14.3833  seconds. 

takes 

14.4000  seconds. 

takes 

14.3833  seconds. 

takes 

14.3834  seconds. 

takes 

14.3833  seconds. 

takes 

14.3834  seconds. 

takes 

11.7333  seconds. 

takes 

14.5667  seconds. 

takes 

14.5667  seconds. 

takes 

14.5667  seconds. 

takes 

14.5667  seconds. 

takes 

14.5667  seconds. 
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Teat  MaMi  A000090 
Clock  rooolution  Baaauraaent  running 
Toot  Doacriptioni 

D«t«n*ln«  clock  resolution  using  second  differences 
of  values  returned  by  the  function  CPU__TiBe_Clock. 

Huiber  of  sasple  values  is  7000 

Clock  Resolution  ■  1.000000000000000  seconds. 

Clock  Resolution  (average)  •  1.000000000000000  seconds. 

Clock  Resolution  (variance)  •  O.OOOOOOOOOOOOOOO  seconds. 


Test  Naasi  A000091  Class  Haeei  Coaposite 

1.2000  is  ties  in  Billiseconds  for  one  Mirystone 
Test  Description! 

Reinhold  P.  Neicker's  OHRYSTONB  coaposite  benchnark 


Teat  Naasi  A000092  Class  Maaat  coapoaite 

Average  tine  per  cycle  i  2784.33  ailliseconda 
Average  tfhetstone  rating  i  359  KWIPS 


Iteration  1 

73717.0000  73717.0000  0.0000 

Test  Iteration  1 
73717.0000  73717.0000  0.0000 

Iteration  2 

73718.0000  73718.0000  0.0000 

Test  Iteration  2 
73718.0000  73718.0000  0.0000 

Iteration  4 

73718.0000  73718.0000  0.0000 

Teat  Iteration  4 
73719.0000  73719.0000  0.0000 

Iteration  8 

73720.0000  73720.0000  0.0000 

Teat  Iteration  8 
73720.0000  73721.0000  1.0000 

Iteration  16 

73721.0000  73721.0000  0.0000 

Teat  Iteration  16 
73721.0000  73723.0000  2.0000 

Iteration  32 

73723.0000  73723.0000  0.0000 

Test  Iteration  32 
73723.0000  73727.0000  4.0000 

Iteration  64 

73727.0000  73727.0000  0.0000 

Teat  Iteration  64 
73727.0000  73734.0000  7.0000 

Iteration  128 

73734.0000  73735.0000  1.0000 

Teat  Iteration  128 
73735.0000  73749.0000  14.0000 

Iteration  256 

73749.0000  73750.0000  l.OOOO 

Test  Iteration  256 
73750.0000  73777.0000  27.0000 

Iteration  512 

73777.0000  73780.0000  3.0000 

Test  Iteration  512 
73780.0000  73834.0000  54.0000 

Iteration  1024 

73834.0000  73839.0000  5.0000 

Test  Iteration  1024 
73839.0000  73947.0000  108.0000 

Teat  Rsnai  COOOOOl  Class  Naaei  Tasking 

CPU  Tiaei  1005.9  aicroseconds 

Nall  Tiaai  1005.9  aicroseconds.  Iteration  Countt  1024 

Teat  Description! 

Task  create  and  temlnate  aeasureaent 

with  one  task,  no  entries,  when  task  is  in  a  procedure 

using  a  task  type  in  a  package,  no  select  statoaent,  no  loop. 


Iteration  1 

73949.0000  73949.0000  0.0000 

Toot  Iteration  1 
73949.0000  73950.0000  1.0000 

Iteration  2 

73950.0000  73950.0000  0.0000 

Teat  Iteration  2 
73950.0000  73950.0000  0.0000 

Iteration  4 

73950.0000  73951.0000  1.0000 

Test  "teration  4 
73951.0000  73951.0000  0.0000 

Iteration  8 

73951.0000  73951.0000  0.0000 

Test  Iterat ion  8 
73952.0000  73953.0000  1.0000 

Iteration  16 

73953.0000  73953.0000  0.0000 

Test  Iteration  16 
73953.0000  73955.0000  2.0000 

Iteration  32 

73955.0000  73955.0000  0.0000 

Teat  Iteration  32 
73955.0000  73959.0000  4.0000 

Iteration  64 

73959.0000  73960.0000  1.0000 

Test  Iteration  64 
73960.0000  73967.0000  7.0000 

Iteration  128 

73967.0000  73968.0000  1.0000 

Test  Iteration  128 
73968.0000  73982.0000  14.0000 

Iteration  256 

73982.0000  73984.0000  2.0000 

Teat  Iteration  256 
73984.0000  74012.0000  28.0000 

Iteration  512 

74012.0000  74015.0000  3.0000 

Test  Iteration  512 
74015.0000  74071.0000  56.0000 

Iteration  1024 

74072.0000  74077.0000  5.0000 

Test  Iteration  1024 
74077.0000  74190.0000  113.0000 

Teat  Haasi  C000002  Claas  Naaet  Tasking 

CPU  Tiaei  1054.7  aicroseconds 

Wall  Tiaei  1054.  7  aicroseconda.  Iteration  Counti  1024 

Test  Description! 

Task  create  and  terainate  tiae  aeasureaent. 

with  one  task,  no  entries  «ihan  task  is  in  a  prooeitare, 

taak  defined  and  used  in  procedure,  no  select  stateeent,  no  loop 


Iteration  1 

74557.0000  74557.0000  0.0000 

Test  Iterat ion  1 
74558.0000  74558.0000  0.0000 

Iteration  2 

74558.0000  74558.0000  0.0000 

Teat  Iterat ion  2 
74559.0000  74559.0000  0.0000 

Iteration  4 

74559.0000  74559.0000  0.0000 

Teat  Iteration  4 
74559.0000  74559.0000  0.0000 

Iteration  • 

74560.0000  74560.0000  0.0000 

Teat  Iteration  8 
74560.0000  74560.0000  0.0000 

Iteration  16 

74560.0000  74561.0000  1.0000 

Test  Iteration  16 
74561.0000  74562.0000  1.0000 

Iteration  32 

74562.0000  74562.0000  0.0000 

Teat  Iteration  32 
74562.0000  74564.0000  2.0000 

Iteration  64 

74564.0000  74565.0000  1.0000 

Teat  Iteration  64 
74565.0000  74568.0000  3.0000 

Iteration  128 

74569.0000  74569.0000  0.0000 

Test  Iteration  128 
74570.0000  74576.0000  6.0000 

Iteration  256 

74576.0000  74578.0000  2.0000 

Test  Iteration  256 
74578.0000  74591.0000  13.0000 

Iteration  512 

74591.0000  74594.0000  3.0000 

Teat  Iteration  512 
74594.0000  74620.0000  26.0000 

Iteration  1024 

74620.0000  74626.0000  6.0000 

Teat  Iteration  1024 

74626.0000  74678.0000  52.0000 

Iteration  2048 

74678.0000  74689.0000  11.0000 

Test  Iteration  2048 

74690.0000  74793.0000  103.0000 

Teat  Hasei  H000004  Class  Naaei  Chapter  13 

CPU  Tiaei  449.2  aicroseconds 

Wall  Tisei  449.2  aicroseconda.  Iteration  Counti  2048 

Test  Description! 

Tiae  to  perform  standard  boolean  operations  on  arrays  of  boolaans. 
Por  this  test  the  arrays  are  MOT  PACnD  with  the  pragaa  'PACK.' 

For  this  test  the  operations  are  performed  on  coiponanta  In  a  loop. 


Iteration  1 

75295.0000  75295.0000  0.0000 

Test  Itaration  1 
75296.0000  75296.0000  0.0000 

Iteration  2 

75296.0000  75296.0000  0.0000 

Test  Iteration  2 
75296.0000  75296.0000  0.0000 

Iteration  4 

75297.0000  75297.0000  0.0000 

Test  Iterstion  4 
75297.0000  75297.0000  0.0000 

Iteration  8 

75297.0000  75297.0000  0.0000 

Test  Iteration  8 
75297.0000  75297.0000  0.0000 

Iteration  16 

75298.0000  75298.0000  0.0000 

Test  Iteration  16 
75298.0000  75298.0000  0.0000 

Iteration  32 

75298.0000  75298.0000  0.0000 

Test  Iteration  32 
75299.0000  75299.0000  0.0000 

Iteration  64 

75299.0000  75299.0000  0.0000 

Test  It  erat ion  6  4 
75300.0000  75300.0000  0.0000 

Iteration  128 

75300.0000  75301.0000  1.0000 

Test  Iterstion  128 
75301.0000  75302.0000  1.0000 

Iteration  256 

75302.0000  75303.0000  1.0000 

Test  Iteration  256 
75304.0000  75305.0000  1.0000 

Iteration  512 

75305.0000  75308.0000  3.0000 

Teat  Iteration  512 
75308.0000  75311.0000  3.0000 

Iteration  1024 

75311.0000  75316.0000  5.0000 

Test  Iteration  1024 

75317.0000  75322.0000  5.0000 

Iteration  2048 

75323.0000  75333.0000  10.0000 

Test  Iteration  2048 

75333.0000  75345.0000  12.0000 

Iteration  4096 

75345.0000  75366.0000  21.0000 

Test  Iteration  4096 

75366.0000  75390.0000  24.0000 

Iteration  8192 

75390.0000  75431.0000  41.0000 

Test  Iteration  8192 

75431.0000  75479.0000  48.0000 

Iteration  16384 

75479.0000  75561.0000  82.0000 

Test  Iteration  16384 
75561.0000  75657.0000  96.0000 

•••••  INCOMPLOTB  WASURBNBirr  ••••• 

Test  Naaei  pOOOOOl  Claas  Naaei  Procedure 

CPU  Tiaei  8.5  aicroseconds 

Wall  Tiaei  8.5  aicroseconds.  Iteration  Counts  16384 

Test  Description! 

Procedure  call  and  return  tiae  (  aay  be  ssro  if  antoaatic  inlining  ) 
procedure  is  local 
no  psraaeters 


Iteration  1 
75659.0000  75659.0000 


0.0000 


TMt  Iteration  1 
7S659.0000  75659.0000  0.0000 

Itamtion  2 

75660.0000  75660.0000  0.0000 

Taat  Itarat ion  2 
75660.0000  75660.0000  0.0000 

Iteration  4 

75660.0000  75660.0000  0.0000 

Teat  Iterat ion  4 
75660.0000  75660.0000  0.0000 

Iteration  8 

75661.0000  75661.0000  0.0000 

Teat  Iterat ion  • 

75661.0000  75661.0000  0.0000 

Iteration  16 

75661.0000  75661.0000  0.0000 

Tent  Iteration  16 
75662.0000  75662.0000  0.0000 

Iteration  32 

75662.0000  75662.0000  0.0000 

Teat  Iteration  32 
75663.0000  75663.0000  0.0000 

Iteration  64 

75663.0000  75663.0000  0.0000 

Teat  Iteration  64 
75664.0000  75664.0000  0.0000 

Iteration  120 

75665.0000  75666.0000  1.0000 

Teat  Iteration  120 
75666.0000  75667.0000  1.0000 

Iteration  256 

75667.0000  75669.0000  2.0000 

Tent  Iteration  256 
75669.0000  75671.0000  2.0000 

Iteration  512 

75671.0000  75675.0000  4.0000 

Teat  Iteration  512 
75675.0000  75679.0000  4.0000 

Iteration  1024 

75679.0000  75605.0000  6.0000 

Teat  Iteration  1024 

75686.0000  75694.0000  0.0000 

Iteration  2048 

75694.0000  75707.0000  13.0000 

Teat  Iteration  2040 

75707.0000  75724.0000  17.0000 

Iteration  4096 

75724.0000  75749.0000  25.0000 

Teat  Iteration  4096 

75749.0000  75703.0000  34.0000 

Iteration  8192 

75704.0000  75833.0000  49.0000 

Teat  Iteration  0192 

75033.0000  75902.0000  69.0000 

Iteration  16384 
75902.0000  76001.0000  99.0000 

Teat  Iteration  16304 
76001.0000  76130.0000  137.0000 

Teat  VaaBi  OOOOOlO  Clean  Naeai  Procedure 

CPU  TiMi  23.2  aicroaeconda 

Nall  Tiaat  23.2  eieroseconda.  Iteration  Count!  16384 

Teat  Oeaeriptioni 

ProccKlure  call  and  return  tiaa  eeaauraeant 

Coapare  to  P000005  _ 

10  paraMtera*  in  IimttR 


Iteration  1 

76140.0000  76140.0000  0.0000 

Teat  Iteration  1 
76140.0000  76140.0000  0.0000 

Iteration  2 

76140.0000  76141.0000  1.0000 

Teat  Iteration  2 
76141.0000  76141.0000  0.0000 

Iteration  4 

76141.0000  76141.0000  0.0000 

Teat  Iteration  4 
76141.0000  76141.0000  0.0000 

Iteration  8 

76142.0000  76142.0000  0.0000 

Teat  Iteration  8 
76142.0000  76143.0000  1.0000 

Iteration  16 

76143.0000  76143.0000  0.0000 

Teat  Iteration  16 
76143.0000  76144.0000  l.OOOO 

Iteration  32 

76144.0000  76144.0000  0.0000 

Teat  Iteration  32 
76145.0000  76146.0000  1.0000 

Iteration  64 

76146.0000  76147.0000  1.0000 

Teat  Iteration  64 
76147.0000  76150.0000  3.0000 

Iteration  120 

76150.0000  76151.0000  1.0000 

Tent  Iteration  120 
76151.0000  76158.0000  7.0000 

Iteration  256 

76150.0000  76159.0000  1.0000 

Teat  Iteration  256 
76160.0000  76173.0000  13.0000 

Iteration  512 

76173.0000  76175.0000  2.0000 

Teat  Iteration  512 
76176.0000  76202.0000  26.0000 

Iteration  1024 

76202.0000  76207.0000  5.0000 

Tent  Iteration  1024 

76207.0000  76259.0000  52.0000 

Iteration  2048 

76259.0000  76270.0000  11.0000 

Taat  Iteration  2040 

76270.0000  76374.0000  104.0000 

Teat  llaaei  TOOOOOl  Clean  Naeei  Tanking 

CPU  Tieei  454.1  elcroaecondn 

Nall  Tieet  454.1  aicroaeconda.  Iteration  Count!  2040 

Teat  Oeaeriptioni 

Hiniaia  rendea voua»  entry  call  and  return  tiea 
1  tank  1  entry  ,  taak  inaide  procedure 


Iteration  1 

76376.0000  76376.0000  0.0000 

Teat  Iteration  1 
76376.0000  76376.0000  0.0000 

Iteration  2 
76377.0000  76377.0000 
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Teat  Iteration  2 
76377.0000  76377.0000  0.0000 

Iteration  4 

76377.0000  76377.0000  0.0000 

Taat  Iteration  4 
76370.0000  76370.0000  0.0000 

Iteration  0 

76370.0000  76370.0000  0.0000 

Teat  Iteration  0 
76379.0000  76380.0000  1.0000 

Iteration  16 

76300.0000  76300.0000  0.0000 

Teat  Iteration  16 
76300.0000  76302.0000  2.0000 

Iteration  32 

76302.0000  76303.0000  1.0000 

Taat  Iteration  32 
76303.0000  76387.0000  4.0000 

Iteration  64 

76307.0000  76307.0000  0.0000 

Taat  Iteration  64 
76307.0000  76395.0000  8.0000 

Iteration  120 

76395.0000  76396.0000  1.0000 

Taat  Iteration  128 
76396.0000  76411.0000  15.0000 

Iteration  256 

76411.0000  76413.0000  2.0000 

Teat  Iteration  256 
76413.0000  76443.0000  30.0000 

Iteration  512 

76443.0000  76446.0000  3.0000 

Teat  Iteration  512 
76446.0000  76507.0000  61.0000 

Iteration  1024 

76507.0000  76512.0000  5.0000 

Teat  Iteration  1024 

76513.0000  76634.0000  121.0000 

Taat  Naaei  T000004  Claae  Haaet  Tasking 

CPU  Tiaei  566.4  aicroaeconds 

Nall  Tiaei  566.4  aicroaeconds.  Iteration  Counti  1024 

Teat  Description  I 

Taak  entry  call  and  return  tiee  eaasured 

One  taaka  active,  two  entriaa,  taaka  in  a  package 

uaing  select  atataeent 


Taat  Naaei  A000090 
Clock  resolution  eaaauroeont  running 
Teat  Deaeriptioni 

Deteraine  clock  resolution  using  second  differences 
of  values  returned  by  the  function  CPU_Tiea_^Clock. 

Nueber  of  aa^le  values  is  7000 

Clock  Resolution  ■  ! .000000000000000  seconds. 

Clock  Resolution  (average)  ■  1.000000000000000  aaconda. 

Clock  Resolution  (variance)  ■  0.000000000000000  seconds. 


Test  Naaei  A000091  Class  Naeet  Co^ioaite 

1.2000  it  tiee  in  eilliseconds  for  one  Dhryatone 
Teat  Description! 

Reinhold  P.  Neieker's  DHRYffTONS  co^ioeite  bencheark 


Taat  Naaei  k000092  Class  Maae!  co«|>osite 

Average  tiee  per  cycle  t  2834.67  eilliseconds 
Aversge  Nhetstone  rating  t  353  KNXPS 


Iteration  1 

77938.0000  77938.0000  0.0000 

Test  Iteration  1 
77938.0000  77939.0000  1.0000 

Iteration  2 

77939.0000  77939.0000  0.0000 

Teat  Iteration  2 
77939.0000  77939.0000  0.0000 

Iteration  4 

77939.0000  77939.0000  0.0000 

Teat  Iteration  4 
77940.0000  77940.0000  O.OODO 

Iteration  8 

77941.0000  77941.0000  0.0000 

Teat  Iteration  8 
77941.0000  77942.0000  1.0000 

Iteration  16 

77942.0000  77942.0000  0.0000 

Test  Iteration  16 
77942.0000  77944.0000  2.0000 

Iteration  32 

77944.0000  77944.0000  0.0000 

Test  Iteration  32 
77945.0000  77948.0000  3.0000 

Iteration  6  4 

77948.0000  77948.0000  0.0000 

Teat  Iteration  64 
77949.0000  77955.0000  6.0000 

Iteration  120 

77956.0000  77956.0000  0.0000 

Test  Iteration  128 
77957.0000  77970.0000  13.0000 

Iteration  256 

77970.0000  77972.0000  2.0000 

Test  Iteration  256 
77972.0000  77999.0000  27.0000 

Iteration  512 

77999.0000  78002.0000  3.0000 

Teat  Iteration  512 
78002.0000  78056.0000  54.0000 

Iteration  1024 

78056.0000  70062.0000  6.0000 

Teat  Iteration  1024 

70062.0000  70170.0000  108.0000 

Teat  Neeei  COOOOOl  Claea  Naeei  Tasking 

CPU  Tieai  996.1  aicroaeconda 

Well  Tiaei  996.1  nicroaeconds.  Iteration  Counti  1024 

Teat  Deaeriptioni 

Task  craate  and  terainate  neaaureeent 

with  one  task,  no  entries,  when  task  la  in  a  procedure 
neing  a  taak  type  in  a  package,  no  select  atateeent,  no  loop. 


Iteration  1 

78173.0000  70173.0000  0.0000 

Test  Iteration  1 
70173.0000  70173.0000 
Iterat ion  2 


0.0000 


0.0000 
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7tl73.0000  7tl73.0000  0.0000 

TMt  It«ration  2 
70173.0000  70174.0000  1.0000 

Itaratlon  4 

70174.0000  70174.0000  0.0000 

TMt  Itaration  4 
70174.0000  70175.0000  1.0000 

Itaratioo  0 

70175.0000  70175.0000  0.0000 

TMt  Itaratlon  0 
70175.0000  70176.0000  1.0000 

Itaration  16 

70176.0000  70176.0000  0.0000 

Teat  Iteration  16 
70176.0000  70170.0000  2.0000 

Iteration  32 

70179.0000  70179.0000  0.0000 

Teat  Iteration  32 
70179.0000  70102.0000  3.0000 

Iteration  64 

70103.0000  70103.0000  0.0000 

Teat  Iteration  64 
70103.0000  78190.0000  7.0000 

Iteration  128 

70191.0000  70191.0000  O.OOOO 

Toot  Iteration  128 
78191.0000  70206.0000  15.0000 

Iteration  256 

78206.0000  78207.0000  1.0000 

Teat  Iteration  256 
70207.0000  78236.0000  29.0000 

Iteration  512 

78236.0000  78239.0000  3.0000 

Teat  Iteration  512 
70239.0000  78296.0000  57.0000 

Iteration  1024 

70296.0000  78302.0000  6.0000 

Teat  Iteration  1024 
70302.0000  70415.0000  113.0000 

Teat  ■aeai  C000002  CLaaa  Maeei  Tanking 

CPU  Tiaet  1044.9  eicroaecondn 

Nall  Tim  1044.9  eicroaecondn.  Iteration  Count*  1024 

Teat  Oeacrlptloni 

Taak  create  and  tereinate  tina  eeaaureennt . 

with  one  taak,  no  entrlea  «dien  tank  la  in  a  procedure/ 

taak  defined  and  uaed  In  procedure/  no  aelect  ntateaent/  no  loop 


Iteration  1 

70703.0000  78783.0000  0.0000 

Teat  Iteration  1 
78703.0000  78783.0000  0.0000 

Iteration  2 

70704.0000  78784.0000  0.0000 

Teat  Iterat ion  2 
70704.0000  78704.0000  0.0000 

Iteration  4 

70704.0000  78704.0000  0.0000 

Teat  Iteration  4 
70704.0000  78785.0000  1.0000 

Iteration  0 

70703.0000  78705.0000  0.0000 

Teat  Iterat ion  8 
70705.0000  70705.0000  0.0000 

Iteration  16 

70706.0000  70786.0000  0.0000 

Teat  Iteration  16 
70706.0000  70707.0000  l.OOOO 

Iteration  32 

70707.0000  70707.0000  0.0000 

Teat  Iteration  32 
70707.0000  70789.0000  2.0000 

Iteration  64 

70709.0000  70790.0000  1.0000 

Teat  Iteration  64 
70790.0000  70793.0000  3.0000 

Iteration  120 

70794.0000  70795.0000  1.0000 

Teat  Iteration  128 
70795.0000  70001.0000  6.0000 

Iteration  256 

70002.0000  70003.0000  l.OOOO 

Tent  Iteration  256 
78003.0000  70816.0000  13.0000 

Iteration  512 

70016.0000  78019.0000  3.0000 

Tent  Iteration  512 
70019.0000  78045.0000  26.0000 

Iteration  1024 

78845.0000  78851.0000  6.0000 

Teat  Iteration  1024 

70051.0000  78903.0000  52.0000 

Iteration  2040 

70903.0000  78914.0000  11.0000 

Tent  Iteration  2040 

70915.0000  79018.0000  103.0000 

Teat  Ham  H000004  Claaa  Nanet  Chapter  13 

CPU  Tine*  449.2  eicroaeconda 

Nall  Tiee*  449.2  eicroaeconda.  Iteration  Count*  2040 

Teat  Oeacrlptloni 

Tina  to  perfore  atandard  boolean  operatlona  on  arrajra  of  booleana. 
For  thin  teat  the  arraya  are  NOT  PACKBO  with  the  pragea  'PACK.' 

For  thin  teat  the  operatlona  are  perfonad  on  oo^Mnenta  In  a  loop. 


Iteration  1 

79504.0000  79504.0000  0.0000 

Tent  Iterat ion  1 
79504.0000  79584.0000  0.0000 

Iteration  2 

79504.0000  79584.0000  0.0000 

Teat  Iteration  2 
79584.0000  79584.0000  0.0000 

Iteration  4 

79585.0000  79585.0000  0.0000 

Teat  Iterat Ion  4 
79505.0000  79585.0000  0.0000 

Iteration  0 

79505.0000  79505.0000  0.0000 

Tent  Iteration  0 
79506.0000  79506.0000  0.0000 

Iteration  16 

79506.0000  79506.0000  0.0000 

Teat  Iteration  16 
79506.0000  79506.0000  0.0000 

Iteration  32 

79507.0000  79507.0000  0.0000 

Teat  Iteration  32 
>9507. 0000  79507.0000 
Iteration  64 


79507.0000  79580.0000  1.0000 

Teat  Iteration  64 
79508.0000  79508.0000  0.0000 

Iteration  120 

79509.0000  79589.0000  0.0000 

Teat  Iteration  128 
79509.0000  79590.0000  1.0000 

Iteration  256 

79591.0000  79592.0000  1.0000 

Teat  Iteration  256 
79592.0000  79594.0000  2.0000 

iteratlfn  512 

79594.0000  79597.0000  3.0000 

Teat  Iteration  512 
79597.0000  79600.0000  3.0000 

Iteration  1024 

79601.0000  79606.0000  5.0000 

Teat  Iteration  1024 

79607.0000  79613.0000  6.0000 

Iteratlcn  2040 

79613.0000  79625.0000  12.0000 

Teat  Iteration  2040 

79625.0000  79630.0000  13.0000 

Iteration  4096 

79630.0000  79661.0000  23.0000 

Teat  Iteration  4096 

79662.0000  79600.0000  26.0000 

Iteration  0192 

79600.0000  79734.0000  46.0000 

Teat  Iteration  8192 

79735.0000  79787.0000  52.0000 

Iteration  16304 

79707.0000  79879.0000  92.0000 

Teat  Iteration  16384 
79880.0000  79904.0000  1C4.0000 

Teat  Maaa*  POOOOOl  Claaa  Majaei  Procedure 

CPU  Tleet  7.3  alcroaeconda 

Nall  Tiaat  7.3  eicroaeconda.  Iteration  Count*  16384 

Teat  Deacrlptioni 

Procedure  call  and  return  tine  (  nay  be  zero  if  autoeatic  Inlining  ) 
procedure  la  local 
no  paraeetera 


Iteration  1 

79986.0000  79986.0000  0.0000 

Teat  Iteration  1 
79986.0000  79986.0000  0.0000 

Iteration  2 

79986.0000  79986.0000  0.0000 

Teat  Iteration  2 
79987.0000  79987.0000  0.0000 

Iteration  4 

79987.0000  79987.0000  0.0000 

Teat  Iteration  4 
79987.0000  79987.0000  0.0000 

Iteration  8 

79987.0000  79988.0000  1.0000 

Taet  Herat  ion  8 
79988.0000  79988.0000  0.0000 

Itaratlon  16 

79988.0000  79988.0000  0.0000 

Teat  Iteration  16 
79988.0000  79988.0000  0.0000 

Iteration  32 

79989.0000  79989.0000  0.0000 

Teat  Iteration  32 
79990.0000  79990.0000  0.0000 

Iteration  64 

79990.0000  79991.0000  1.0000 

Teat  Iteration  64 
79991.0000  79991.0000  0.0000 

Iteration  128 

79992.0000  79993.0000  1.0000 

Test  Iteration  128 
79993.0000  79994.0000  1.0000 

Iteration  256 

79994.0000  79996.0000  2.0000 

Teat  Iteration  256 
79996.0000  79999.0000  3.0000 

Iteration  512 

79999.0000  80002.0000  3.0000 

Teat  Itaratlon  512 
80002.0000  80007.0000  5.0000 

Iteration  1024 

80007.0000  80013.0000  6.0000 

Teat  Iteration  1024 

80014.0000  80022.0000  8.0000 

Iteration  2048 

80023.0000  80036.0000  13.0000 

Teat  Iteration  2048 

80036.0000  80053.0000  17.0000 

Iteration  4096 

80054.0000  80080.0000  26.0000 

Teat  Iteration  4096 

80080.0000  80115.0000  35.0000 

Iteration  8192 

80115.0000  80168.0000  53.0000 

Test  Iteration  8192 

80168.0000  80238.0000  70.0000 

Iteration  16384 

80238.0000  80343.0000  105.0000 

Teat  Iteration  16384 
80343.0000  80482.0000  139.0000 

Test  Naeai  POOOOlO  Class  Naaei  Procedure 

CPU  Tleei  20.8  BicroaeTOnda 

Nall  Tiaai  20.8  eicroaeconda.  Iteration  Cocnti  16384 

Teat  Deacrlptioni 

Frocadure  call  and  return  tiee  eeaeurceont 
Coipare  to  P000005 
10  paraeetera/  In  INTN(XP 


Iteration  I 

80485.0000  80485.0000  0.0000 

Teat  Iteration  1 
80485.0000  80485.0000  0.0000 

Iteration  2 

80485.0000  80485.0000  0.0000 

Teat  Iterat ion  2 
80486.0000  80486.0000  0.0000 

Xteratlcn  4 

80486.0000  80486.0000  0.0000 

Teat  Iteration  4 
80486.0000  80486.0000  0.0000 

Iteration  t 

80486.0000  80487.0000  1.0000 

Test  Iteration  8 
80487.0000  80487.0000  0.0000 

Iteration  16 


0.0000 


•0417.0000  804a0.0000  1.0000 

TMt  Iteration  14 
804l».0000  80489.0000  1.0000 

Iteration  32 

•0489.0000  80489.0000  O.OOCO 

Teet  Iteration  32 
80489.0000  80491.0000  2.0000 

Iteration  64 

80491.0000  80491.0000  0.0000 

Toot  Iteratioa  64 
•0492.0000  80499.0000  3.0000 

Iteration  128 

80495.0000  80496.0000  1.0000 

Teet  Iteration  128 
80496.0000  80502.0000  6.0000 

Iteration  256 

80502.0000  80504.0000  2.0000 

Teat  Iteration  256 
80504.0000  80517.0000  13.0000 

Iteratioa  512 

80517.0000  80520.0000  3.0000 

Teet  Iteration  512 
80520.0000  80545.0000  25.0000 

Itf^n'-lon  1024 

80546.0000  80551.0000  5.0000 

Teat  Iteration  1024 

80531.0000  80602.0000  51.0000 

Iteration  2048 

•0602.0000  80613.0000  11.0000 

Teet  Iteration  2048 

80614.0000  80715.0000  101.0000 

Teat  Naeai  TOOOOOl  Claaa  NoMt  Taakinq 

CPU  Tinei  439.5  elcroaeconda 

Nall  Tlaai  439.5  alcroaeconds.  Iteratioa  Counti  2040 

Teat  Oeacriptiont 

NlnlauB  rendeavona,  entry  call  and  return  tine 
1  tank  I  entry  ,  taak  Inalde  procedure 
no  aeleet 


Iteration  I 

80718.0000  80718.0000  0.0000 

Teat  Iteration  1 
80718.0000  80718.0000  0.0000 

Iteration  2 

•0718.0000  80718.0000  0.0000 

Teat  Iteration  2 

Iteration  4 

80719.0000  80719.0000  0.0000 

Teet  Iterat ion  4 
80719.0000  80720.0000  1.0000 

Iteral ion  8 

8072'). 0000  80720.0000  0.0000 

Teat  Iteration  8 
80720.0000  80721.0000  1.0000 

Iteration  16 

80722.0000  80722.0000  0.0000 

Teat  Iteration  16 
80722.0000  80724.0000  2.0000 

Iteration  32 

80724.0000  80724.0000  0.0000 

Teat  Iteratioa  32 
80724.0000  80728.0000  4.0000 

Iteration  64 

•0728.0000  80729.0000  1.0000 

Teat  Iteration  64 
80729.0000  80736. OOuO  7.0000 

Iteration  128 

80737.0000  80737.0000  0.0000 

Teat  Iteratioa  128 
80738.0000  80752.0000  14.0000 

Iteration  256 

80753.0000  80754.0000  1.0000 

Taat  Itaration  256 
80754.0000  80784.0000  30.0000 

Iteration  512 

80784.0000  00787.0000  3.0000 

Teat  Iteration  512 
80787.0000  80847.0000  60.0000 

Iteration  1024 

80847.0000  10853.0000  6.0000 

Teat  Iteration  1024 
80853.0000  80972.0000  119.0000 
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Iteration  64 

37491.0000  37492.0000  1.0000 

Iteration  128 

37499.0000  37500.0000  1.0000 

Itaration  256 

37514.0000  37515.0000  1.0000 

Itaration  512 

37543.0000  37546.0000  3.0000 

Iteration  1024 

37600.0000  37606.0000  6.0000 

Teat  Hanai  COOOOOl  Claaa  Manei  Tasking 

CPU  Tinei  1005.9  eteroaeeonda 

Mall  Tinei  1005.9  nioroaeconda.  Iteration  Coanti  1024 

Taat  Deacription I 

Taak  create  and  teminate  naaaareeent 

with  one  task,  no  antriea,  when  taak  is  in  a  procedure 

oalng  a  taak  type  in  a  package^  no  aeleet  atateeent,  no  loop. 


Iteration  1 

37718.0000  37718.0000  0.0000 

Iteration  2 

37718.0000  37718.0000  0.0000 

Iteration  4 

37719.0000  37719.0000  0.0000 

Iteration  8 

37719.0000  37719.0000  0.0000 

Iteration  16 

37720.0000  37720.0000  0.0000 

Iteration  32 

37723.0000  37723.0000  0.0000 

Itaration  64 

37726.0000  37727.0000  1.0000 

Iteration  128 

37734.0000  37735.0000  1.0000 

Iteration  256 

37749.0000  37751.0000  2.0000 

Iteration  512 

37779.0000  37782.0000  3.0000 

Iteration  1024 

37839.0000  37845.0000  6.0000 

Test  Haeei  C000002  Class  Kas»i  Tasking 

CPU  Tinei  1054.7  eicroseconds 

Mall  Tieei  1054.7  eicroBsconds.  Iteration  Counts  1024 

Test  Deacription I 

Taak  create  and  teminate  tine  neaaurenent. 

with  one  taak,  no  entries  when  taak  is  in  a  procedure, 

task  defined  and  used  in  procedure,  no  select  atatenent,  no  loop 


Iteration  1 

38327.0000  38327.0000  0.0000 

Iteration  2 

38328.0000  38328.0000  0.0000 

Iteration  4 

38328.0000  38328.0000  0.0000 

Iteration  8 

38328.0000  38329.0000  1.0000 

Iteration  16 

38329.0000  38329.0000  0.0000 

Iteration  32 

38330.0000  38330.0000  0.0000 

Iteration  64 

38332.0000  38333.0000  1.0000 

Itaration  128 

38336.0000  38337.0000  1.0000 

Itaration  256 

38343.0000  38345.0000  2.0000 

Iteration  512 

38358.0000  38361.0000  3.0000 

Iteration  1024 

38387.0000  38392.0000  5.0000 

Itaration  2048 

38444.0000  38455.0000  11.0000 

Teat  Ham  H000004  Claaa  Haaei  Chapter  13 

CPU  Tinei  449.2  eicroseconds 

Mall  Tinai  449.2  eicroseconds.  Iteration  Countt  2048 

Taat  Deacript  if>n  i 

Tine  to  perfom  atandard  boolean  operationa  on  arrays  of  boolaana. 
For  thia  teet  the  arrays  are  MOT  PACKBD  with  the  pragna  'PACl.' 

For  this  taat  the  operations  are  perfomed  on  cotton  ants  in  a  loop. 


Test  Mansi  T000004  Class  Hanei  Tasking 

CPU  Tinei  551.8  nicro seconds 

Nall  Tinei  551.8  nicroaeconds.  Iteration  Counti  1024 

Teat  Description! 

Task  entry  call  and  return  tine  eeaaured 

One  taaks  active,  two  entries,  taska  in  a  (Mchage 

using  select  atatenent 


Teet  Hanei  k000090 
Clock  reeolution  neaeurenent  running 
Teet  Description  I 

Detemine  clock  resolution  using  second  differences 
of  values  returned  by  the  function  CPU_TlnB_Clock. 

Nuaber  of  aaeple  values  is  7000 

Clock  Resolution  e  1.000000000000000  seconds. 

Clock  Resolution  (average)  •  1.000000000000000  seconds. 

Clock  Resolution  (variance)  •  0.000000000000000  seconds. 


Test  Mansi  A000091  Class  Nonet  Co^KMite 

1.2000  is  tine  in  eilLiseconda  for  one  Ohrystone 
Test  Deacript ion t 

Relnhold  P.  Hsieker’s  DHRySTOHI  composite  benchaark 


Test  Manet  M00093  Claaa  Msnsi  coigxmite 

Average  tine  par  cycle  t  2845.33  aillisecxMida 
Average  Mhetntone  rating  i  351  RNIPS 


Iteration  1 

37482.0000  37482.0000  0.0000 

Iteration  2 

37483.0000  37483.0000  0.0000 

Iteration  4 

37483.0000  37483.0000  0.0000 

Iteration  8 

37484.0000  37484.0000  0.0000 

Iteration  16 

37485.0000  37485.0000  0.0000 

Iteration  32 

37487.0000  37488.0000  1.0000 


Iteration  1 

39118.0000  39118.0000  0.9000 

Iteration  2 

39119.0000  39119.0000  0.0000 

Iteration  4 

39119.0000  39119.0000  0.0000 

Iteration  8 

39119.0000  39119.0000  0.0000 

Iteration  16 

39119.0000  39120.0000  1.0000 

Iteration  32 

39120.0000  39120.0000  0.0000 

Iteration  64 

39120.0000  39121.0000  1.0000 

Itaration  128 

39121.0000  39122.0000  1.0000 

Iteration  256 

39123.0000  39125.0000  2.0000 

Iteration  512 

39126.0000  39129.0000  3.0000 

Iteration  1024 

39133.0000  39138.0000  5.0000 

Iteration  2048 

39145.0000  39156.0000  ll.OOOO 

Iteration  4096 

39169.0000  39192.0000  23.0000 

Iteration  8192 

39217.0000  39262.0000  45.0000 

Iteration  16384 
39313.0000  39403.0000  90.0000 

Teat  MaHi  POOOOOl  Claas  Manet  Procedure 

CPU  Tinei  7.9  nicrosemnda 

Mall  Tiaet  7.9  nirro seconds.  Iteration  Countt  16384 

Teat  Description! 

Procedure  call  and  return  tine  (  nay  be  aero  if  autonatic  inlining  ) 
procedure  is  local 
no  parsnetera 


Iteration  1 

39508.0000  39508.0000  0.0000 

Iteration  2 

39509.0000  39509.0000  0.0000 

Iterat ion  4 
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39509.0000  39509.0000  0.0000 

Iteration  I 

39509.0000  39509.0000  0.0000 

Itaration  10 

39510.0000  39510.0000  0.0000 

Itaratlon  32 

39510.0000  39510.0000  0.0000 

Itaration  04 

39511.0000  39511.0000  0.0000 

Itaratlon  120 

39512.0000  39513.0000  1.0000 

Itaratlon  250 

39514.0000  39515.0000  l.OOOO 

Itaratlon  512 

39510.0000  39521.0000  3.0000 

Itaratlon  1024 

39525.0000  39532.0000  7.0000 


Itaratlon  2040 

39540.0000  39553.0000  13.0000 

Itaratlon  4090 

39549.0000  39594.0000  25.0000 

Itaratlon  8192 

39427.0000  39478.0000  51.0000 

Itaratlon  14384 
39742.0000  39844.0000  102.0000 

Taat  llaa»i  POOOOlO  Claaa  Maaai  Procadura 

CPU  Tlaai  15.9  alcroaaconda 

Wall  Tiaai  14.5  aicrosaoonda.  Iteration  Count*  14384 

Taat  Description  I 

Procadura  call  and  return  tiaa  ■eaauroaent 
Co^>ara  to  P000005 
10  parMaterat  In 


Itaratlon  1 

39974.0000  39974.0000  0.0000 

Itaration  2 

39974.0000  39974.0000  0.0000 

Iteration  4 

39974.0000  39974.0000  0.0000 

Iteration  8 

39977.0000  39977.0000  0.0000 

Itaration  14 

39978.0000  39978.0000  0.0000 

Itaration  32 

39979.0000  39979.0000  0.0000 

Itaration  44 

39981.0000  39981.0000  0.0000 

Itaration  128 

39985.0000  39985.0000  0.0000 

Itaratlon  254 

39992.0000  39993.0000  1.0000 

Itaration  512 

40007.0000  40009.0000  2.0000 

Itaratlon  1024 

40035.0000  40041.0000  4.0000 

Itaratlon  2048 

40093.0000  40104.0000  11.0000 

Taat  Waaai  TQOOOOl  Class  Waaai  Taskinq 

CPU  TIjmi  454.1  aiccoaaoonds 

Wall  Tina*  454.1  aiero seconds.  Itaratlon  Count*  2048 

Taat  Daaeriptloni 

Niniaua  mndaivoos<  entry  call  and  return  tlae 
1  task  1  entry  ,  task  Inside  procedure 
no  select 


Iteration  1 

40210.0000  40210.0000  0.0000 

Iteration  2 

40210.0000  40210.0000  0.0000 

Iteration  4 

40211.0000  40211.0000  0.0000 

Itaration  8 

40212.0000  40212.0000  0.0000 

Itaration  14 

40213.0000  40213.0000  0.0000 

Iteration  32 

40215.0000  40215.0000  0.0000 

Iteration  44 

40219.0000  40220.0000  1.0000 

Itaration  128 

40228.0000  40228.0000  0.0000 

Iteration  254 

40244.0000  40245.0000  1.0000 

Itaration  512 

40274.0000  40279.0000  3.0000 

Iteration  1024 

40340.0000  40344.0000  4.0000 

Tent  llaeai  T000004  Class  Naaei  Tasking 

CPU  Tlaai  571.3  aicroseconda 

Wall  Tiaa*  571.3  aicroseconda.  Iteration  Count*  1024 

Teat  Description* 

Task  entry  call  and  return  tiae  aoasured 

Oite  tasks  active,  two  entriaa.  tasks  in  a  package 

using  select  stateaent 


Teat  NaBBi  A000090 
Clock  resolution  aaasureaent  running 
Tent  Description* 

Deterelne  clock  reaolutlcn  using  second  differences 
of  values  returned  by  the  function  CPU_Tia»_Clock. 

Wunber  of  saig>le  values  Is  7000 

Clock  Resolution  ■  1.000000000000000  seconds. 

Clock  Resolution  (average)  ■  1.000000000000000  seconds. 

Clock  Resolution  (variance)  •  0.000000000000000  seconds. 


Test  Naaat  k000091  Claaa  Waae*  Co^iosite 

1.2000  is  tins  in  ailliaeccnds  for  one  Dhrystone 
Teat  Description* 

Reinhold  P.  Iteicker's  DHRYSTOWC  cosgwsite  bencheark 


Teat  Raaei  A000092  Class  Raast  co^>oaite 

Average  tiae  per  cycle  i  2804.00  ailllsecoTKls 
Average  Whetatone  rating  i  357  KWIPS 


Iteration  1 

77817.0000  77817.0000  0.0000 

Iteration  2 

77818.0000  77818.0000  0.0000 

Iteration  4 
77818.0000  77818.0000 


Iteration  8 

77819.0000  77819.0000  0.0000 

Itaration  14 

77820.0000  77820.0000  0.0000 

Itaratlon  32 

77822.0000  77822.0000  0.0000 

Iteration  44 

77824.0000  77824.0000  0.0000 

Itaratlon  128 

77833.0000  77833.0000  0.0000 

Iteration  254 

77847.0000  77848.0000  1.0000 

Iteration  512 

77875.0000  77878.0000  3.0000 

Itaration  1024 

77932.0000  77937.0000  5.0000 

Test  Wane*  COOOOOl  Clasa  Maaei  Tasking 

CPU  Tiaa*  994.1  aicrosaconds 

Wall  Tins*  996.1  aicroseconda.  Iteration  Count*  1024 

Taat  Daaeriptloni 

Taak  crests  and  tereinate  eeasureeent 

with  ona  taak«  no  antriea,  when  task  is  in  a  procedure 
using  a  task  type  In  a  pacluge/  no  select  stateaent,  no  loop, 


Iteration  1 

78044.0000  78044.0000  0.0000 

Iteration  2 

78047.0000  78047.0000  0.0000 

Iteration  4 

78047.0000  78047.^000  0.0000 

Iteration  8 

78048.0000  78048.0000  0.0000 

Itaration  14 

78049.0000  78049.0000  0.0000 

Itaration  32 

78051.0000  78051.0000  0.0000 

Iteration  44 

78055.0000  ;8054.0000  1.0000 

Itaratlon  128 

78043.0000  78044.0000  1.0000 

Itaration  256 

78078.0000  78080.0000  2.0000 

Itaration  512 

78108.0000  78111.0000  3.0000 

.  eration  1024 

<8147.0000  78172.0000  5.0000 

Teat  Maeat  C000002  Class  Naee*  Tasking 

CPU  Tien*  1054.7  aicroseconds 

Wall  Ties*  1054.7  aicroseconds.  Iteration  Count*  1024 

Teat  Description  I 

Task  oreata  and  tareinate  ties  eeaBoraaent. 

with  ona  taak,  no  antriaa  whan  taak  is  in  a  procedure, 

taak  definad  and  used  in  procedure,  no  select  stateeant,  no  loop 


Iteration  1 

78451.0000  78451.0000  0.0000 

Itaration  2 

78451.0000  78451.0000  0.0000 

Itaration  4 

78452.0000  78452.0000  0.0000 

Iteration  8 

78453.0000  78453.0000  0.0000 

Iteration  14 

78453.0000  78654.0000  1.0000 

Itaration  32 

78455.0000  78455.0000  0.0000 

Itaration  44 

78457.0000  78657.0000  0.0000 

Iteration  128 

78440.0000  78441.0000  1.0000 

Iteration  254 

78468.0000  78449.0000  l.OOOO 

Iteration  512 

78483.0000  78685.0000  2.0000 

Iteration  1024 

78712.0000  78718.0000  4.0000 

Iteration  2048 

78770.0000  78781.0000  11.0000 

Taat  Naeai  K000004  Class  Nanet  Chapter  13 

CPU  Tuwi  449.2  aicroseconds 

Wall  Ties*  449.2  eicroseconda.  Iteration  Count*  2048 

Test  Description* 

Tien  to  perfore  standard  boolean  operationa  on  arraya  of  boolaans. 
For  this  test  the  arrays  are  WCT  PACKED  with  the  pragna  'PACK.  ’ 

For  thia  test  the  operationa  are  perforeed  on  co^xviants  in  a  loop. 


Iteration  1 

79400.0000  79400.0000  0.0000 

Iteration  2 

79400.0000  79400.0000  0.0000 

Iteration  4 

79401.0000  79401.0000  0.0000 

Itaration  8 

79401.0000  79401.0000  0.0000 

Iteration  14 

79401.0000  79401.0000  0.0000 

Iteration  32 

79402.0000  79402.0000  0.0000 

Iteration  44 

79402.0000  79402.0000  0.0000 

Iteration  128 

79403.0000  79404.0000  1.0000 

Iteration  254 

79405.0000  79404.0000  1.0000 

Iteration  512 

79408.0000  79410.0000  2.0000 

Iteration  1024 

79414.0000  79419.0000  5.0000 

Iteration  2048 

79425.0000  79434.0000  11.0000 

Iteration  4094 

79448.0000  79449.0000  21.0000 

Iteration  8192 

79494.0000  79534.0000  42.0000 

Ztemtion  14384 

79585.0000  79470.0000  85.0000 

•••«•  IWCCMPLBTB  WASUKEMEWT  ••••• 

Teat  Raeei  POOOOOl  Class  Wane*  Procedure 

CPU  Tine*  7.9  eicroseconds 

Wall  Tisei  7.9  aioroaecenda.  Iteration  Count t  16384 

Test  Deecriptioni 

Procedure  call  and  return  tine  (  aay  be  seto  if  autonatic  inlining  ] 
procedure  la  local 
no  paraaetera 


0.0000 


0.0000 


Ztaratlon  1 

70770.0000  79770.0000  0.0000 

Iteration  2 

79770.0000  79770.0000  0.0000 

Itaration  4 

79770.0000  79771.0000  1.0000 

Iteration  8 

79771.0000  79771.0000  0.0000 

Itaratloa  16 

79771.0000  79771.0000  0.0000 

Itaration  32 

79772.0000  79772.0000  0.0000 

Itaration  64 

79773.0000  79773.0000  0.0000 

Itaration  120 

79774.0000  7977S.OOOO  1.0000 

Itaration  256 

79776.0000  79778.0000  2.0000 

Itaration  512 

79780.0000  79783.0000  3.0000 

Itaration  1024 

79788.0000  79794.0000  6.0000 

Iteration  2048 

79803.0000  79816.0000  13.0000 

Itaration  4096 

79833.0000  79860.0000  27.0000 

Itaration  8192 

79894.0000  79947.0000  53.0000 

ItaraticM  16384 
80014.0000  80120.0000  106.0000 

Teat  Maaai  POOOOlO  Claaa  Maaet  Procadura 

CPU  Tiaat  17.7  aicroaaconda 

ttall  Tiaat  17.7  aicroaaconda.  Iteration  Countt  16384 

Test  Deacrlptioni 

Procedure  call  and  return  tiae  aeasureaent 

Coa|>ara  to  P000005  _ 

10  paraaetarSf  in  nmcCR 


Iteration  1 

80257.0000  80257.0000  0.0000 

Iteration  2 

80258.0000  80258.0000  0.0000 

Iteration  4 

80258.0000  80258.0000  0.0000 

Itaration  8 

80258.0000  80258.0000  0.0000 

Iteration  16 

80259.0000  80259.0000  0.0000 

Itaration  32 

80260.0000  80260.0000  0.0000 

Itaration  64 

80262.0000  80262.0000  0.0000 

Itaration  128 

80266.0000  80267.0000  1.0000 

Itaration  256 

80273.0000  80275.0000  2.0000 

Itaration  512 

80288.0000  80290.0000  2.0000 

Iteration  1024 

80317.0000  80322.0000  5.0000 

Iteration  2048 

80374.0000  80385.0000  11.0000 

Teat  Haaat  TOOOOOl  Claaa  Maaei  TaakinQ 

CPU  Tiaat  449.2  aicroaaconda 

trail  Tinai  449.2  aicroaaconda.  Itaration  Counti  2048 

Teat  Oaaeriptioni 

NlniaDa  randeavooa,  entry  call  and  ratom  tiaa 
1  task  1  entry  ,  task  inside  procadora 
no  aalaet 


Itaration  I 

80491.0000  80491.0000  0.0000 

Iteration  2 

80491.0000  80491.0000  0.0000 

Itaration  4 

80491.0000  80491.0000  G.OOOO 

Itaration  8 

80492.0000  80492.0000  0.0000 

Itaration  16 

80494.0000  80494.0000  0.0000 

Itaration  32 

80496.0000  80496.0000  0.0000 

Iteration  64 

80500.0000  80501.0000  1.0000 

Iteration  128 

80508.0000  80509.0000  1.0000 

Iteration  256 

80524.0000  80525.0000  1.0000 

Iteration  512 

80555.0000  80558.0000  3.0000 

Itaration  1024 

80618.0000  80623.0000  5.0000 

Teat  Naaei  T000004  CLaas  Naasi  TBakin9 

CPU  Tiaai  561.5  aicroaeconds 

Hall  Tiaa*  561.5  aicroaaconda.  Itaration  Count*  1024 

Teat  Oaaeriptioni 

Task  entry  call  and  return  tiae  aesaurad 

one  taaka  active/  two  entries/  tasks  in  a  package 

using  select  atateaent 


Test  Naaei  k000090 
Clock  resolution  aeasureaent  running 
Teat  Description! 

Oetereine  clock  resolution  using  second  differences 
of  valuea  returned  by  the  function  CPU_Tiae_C lock . 

Nuaber  of  aaaple  valuea  la  7000 

Clock  Resolution  •  1.000000000000000  seconds. 

Clock  Resolution  (average)  ■  1.000000000000000  aeconda. 

Clock  Resolution  (variance)  ■  0.000000000000000  aeconda. 


Teat  Naaei  M00091  Class  Naaei  Co^waite 

1.1000  la  tiae  in  ailliseconds  for  one  Ohryatone 
Teat  Oeeeriptiont 

Reinhold  P.  Neieker'a  DHRTCTOm  coapoalte  benchaark 


Teat  Naaat  M00092  Class  Naaai  coaposite 

Rvarage  tiae  per  cycle  t  2824.67  ailli aeconda 


110 

Iteration  1 
82935.0000  82935.0000 
Iteration  2 
82936.0000  82936.0000  0.0000 

Iteration  4 

82936.0000  82936.0000  0.0000 

Iteration  8 

82937.0000  82937.0000  0.0000 

Iteration  16 

82938.0000  82938.0000  0.0000 

Iteration  32 

82940.0000  82940.0000  0.0000 

Iteration  64 

82944.0000  82944.0000  0.0000 

Iteration  128 

82951.0000  82952.0000  1.0000 

Iteration  256 

82965.0000  82967.0000  2.0000 

Iteration  512 

82994.0000  82996.0000  2.0000 

Iteration  1024 

83051.0000  83056.0000  5.0000 

Teat  Naaai  COOOOOl  Class  Naaei  Tasking 

CPU  Tiaat  996.1  aicroaeconds 

Nall  Tiaei  996.1  aicroaeconds.  Iteration  Counti  1024 

Teat  Oeacript ion i 

Task  create  and  terainate  BBSsureaMnt 

with  one  task/  no  antriea/  when  task  is  in  a  procedure 
uaing  a  task  type  in  a  package/  no  select  atateaent/  no  loop. 


Iteration  1 

83167.0000  83167.0000  0.0000 

Iteration  2 

83167.0000  83167.0000  0.0000 

Iteration  4 

83168.0000  83168.0000  0.0000 

Iteration  8 

83168.0000  83168.0000  0.0000 

Iteration  16 

83169.0000  83170.0000  1.0000 

Iteration  32 

83172.0000  83172.0000  0.0000 

Iteration  64 

83176.0000  83176.0000  0.0000 

Iteration  128 

83184.0000  83185.0000  1.0000 

Itaration  256 

83199.0000  83200.0000  1.0000 

Iteration  512 

83229.0000  83232.0000  3.0000 

Iteration  1024 

83289.0000  83294.0000  5.0000 

Test  Naaei  C000002  Clasa  Naaei  Tasking 

CPU  Tiaei  1064.5  eicroseconds 

Nall  Tiaei  1064.5  eicroaeconds.  Iteration  Counti  1024 

Teat  Oeacript ion  I 

Task  create  and  terainate  tine  neasurenent. 

with  one  taak,  no  entries  when  task  is  in  a  procedure/ 

task  defined  and  used  in  procedure/  no  select  atatenent/  no  loop 


Iteration  1 

83774.0000  83774.0000  0.0000 

Iteration  2 

83774.0000  83774.0000  0.0000 

Iteration  4 

83775.0000  83775.0000  0.0000 

Iteration  8 

83775.0000  83775.0000  0.0000 

Iteration  16 

83776.0000  83776.0000  0.0000 

Iteration  32 

83777.0000  83778.0000  1.0000 

Iteration  64 

83779.0000  83780.0000  1.0000 

Iteration  128 

83783.0000  83784.0000  1.0000 

Iteration  256 

83791.0000  83792.0000  l.OO^O 

Iteration  512 

83805.0000  83808.0000  3.0000 

Iteration  1024 

83834.0000  83840.0000  6.0000 

Iteration  2048 

83892.0000  83904.0000  12.0000 

Test  Naaei  H000004  Claaa  Naaei  Chapter  13 

CPU  Tiaei  449.2  aicroaeconds 

Nall  Tiaei  449.2  aicroaeconds.  Iteration  Counti  2048 

Test  Description! 

Tiae  to  parfora  standard  boolean  operations  on  arrays  of  booleana. 
Por  this  test  the  arrays  are  NOT  PRCKBD  with  the  pragma  'PACK.' 

Por  this  taut  the  operations  are  performed  on  co^Mnenta  in  a  loop. 


Iteration  1 

84523.0000  84523.0000  0.0000 

Iteration  2 

84523.0000  84523.0000  0.0000 

Iteration  4 

84523.0000  84523.0000  0.0000 

Iteration  8 

84524.0000  84524.0000  0.0000 

Iteration  16 

84524.0000  84524.0000  0.0000 

Iteration  32 

84524.0000  84524.0000  0.0000 

Iteration  64 

84525.0000  84525.0000  0.0000 

Iteration  128 

84526.0000  84526.0000  0.0000 

Iteration  256 

84527.0000  84529.0000  2.0000 

Iteration  512 

84531.0000  84533.0000  2.0000 

Iteration  1024 

84536.0000  84542.0000  6.0000 

Iteration  2048 

84548.0000  84559.0000  11.0000 

Iteration  4096 

84571.0000  84592.0000  21.0000 

Iteration  8192 

84617.0000  84659.0000  42.0000 

Iteration  16384 

84708.0000  84793.0000  85.0000 

**•••  INCOnPLBTB  WASURiMlNT  ••••• 

Bt  POOOOOl 

I  7.9  aicroaeconds 


Average  Nhetatone  rat ing  i  354  RNtPS 


Test  Naae 
CPU  Tiaei 


C  less  Ni 


Procedure 


■IcroMcond*. 


7teratlan  Count 


111 


Mall  TiMi  7.9 

Toat  Ooocriptiont 
Prooodura  call  and  return  ties  (  eay 
procedure  la  local 
no  paroaetera 


I  163a4 


be  lero  if  autoaatlc  iDlinlAQ  ) 


Average  tiae  per  cycle  t  -342751.67  ellliaacoada 
Average  Mbetstone  rating  i  211  EMIPS 


Iteration  1 
•4993.0000  64093.0000 
Iteration  2 
84«93.0000  14093.0000 
Iteration  4 
04093.0000  04093.0000 
Iteration  0 
•4093.0000  04094.0000 
Iteration  14 
•4094.0000  04094.0000 
Iteration  32 
04094.0000  04094.0000 
Iteration  64 
0409S.0000  04096.0000 
Iteration  120 
•4097.0000  04097.0000 
Iteration  256 
•4099.0000  04900.0000 
Iteration  512 
•4903.0000  04906.0000 
Iteration  1024 
04911.0000  04917.0000 
Iteration  2040 
04926.0000  04939.0000 
Iteration  4096 
04956.0000  04903.0000 
Iteration  0192 
05016.0000  05069.0000 
Iteration  16304 
05137.0000  05243.0000 


0.0000 

0.0000 

0.0000 

1.0000 

0.0000 

0.0000 

1.0000 

0.0000 

1.0000 

3.0000 

6.0000 

13.0000 

27.0000 

53.0000 

106.0000 


Itaration 

142.0000 

Iteration 

142.0000 

Iteration 

143.0000 

Iteration 

144.0000 

Iteration 

145.0000 

Iteration 

147.0000 

Iteration 

150.0000 

Iteration 

150.0000 

Iteration 

172.0000 

Iteration 

201.0000 

Iteration 

257.0000 


142.0000 

142.0000 

143.0000 

144.0000 

145.0000 

147.0000 

151.0000 

120 

150.0000 

256 

173.0000 

512 

203.0000 

1024 

263.0000 


64 


0.0000 

0.0000 

0.0000 

0.0000 

0.0000 

0.0000 

1.0000 

0.0000 

1.0000 

2.0000 

6.0000 


Teat  Manet  COOOOOl  CUas  Moaet  Taaking 

CPU  Tiaei  996.1  nicroeeconda 

Mall  Tiaei  996.1  nicroeeoonde.  Iteration  Counti  1024 

Teet  Deacriptiont 

Taak  create  and  terninate  neaauranent 

with  one  teak,  no  antriea,  when  tank  ia  in  a  procedure 
uaing  a  tank  type  in  a  package,  no  aelect  atateaent,  no  loop. 


Teat  HaMi  POOOOlO 

CPU  Tiaei  17,7  eicroaecondn 

Mall  Tiaai  I .  7  aicrooeconda. 

Teat  Deacriptl^ni 

Procedure  call  and  return  tine  neaauritnant 

Coapore  to  P000005  _ 

10  paroaetera,  in  nmceft 


Claan  Haaei  Procedure 
Iteration  Count!  16394 


Iteration  1 

•5390.0000  •5300.0000  0.0000 

Iteration  2 

•5390.0000  OOIOO.OOOO  0.0000 

Iteration  4 

•5301.0000  •5301.0000  0.0000 

Iteration  • 

•5391.000a  95391.0000  0.0000 

Iteration  16 

•5393.0000  95392.0000  0.0000 

Iteration  32 

•5393.0000  •5391.0000  0.0000 

Iteration  64 

•5395.0000  95395.0000  0.0000 

Iteration  129 

95399.0000  95399.0000  0.0000 

Iteration  256 

•5396.0000  95397.0000  1.0000 

Iteration  512 

•5411.0000  95413.0000  2.0000 

Iteration  1024 

95440.0000  95445.0000  5.0000 

Iteration  2049 

95497.0000  95509.0000  11.0000 


Teat  Maeet  TOOOOOl  Ciaan  Hoaei  Tacking 

CPU  Tiaei  454.  1  nicroeeconda 

Mall  Tlnni  454.1  nicroaeoonda.  Iteration  Counti  2049 

Test  Deacrlptioni 

Hiniaia  rendeavous,  entry  call  and  return  t lae 
1  taak  1  entry  t  task  inside  procedure 
no  aelect 


Iteration  1 

•5614.0000  95614.0000  0.0000 

Tferation  2 

95615.0000  95615.0000  0.0000 

Iteration  4 

95615.0000  95615.0000  0.0000 

Iteration  9 

95616.0000  95616.0000  0.0000 

Iteration  16 

95617.0000  95617.0000  0.0000 

Iteration  32 

•5620.0000  95620.0000  0.0000 

Iteration  64 

95624.0000  95624. OOOu  0.0000 

Iteration  129 

95632.0000  95633.0000  1.0000 

Iteration  256 

95649.0000  95649.0000  1.0000 

Iteration  512 

•5679.0000  95692.0000  3.0000 

Iteration  1024 

•5741.0000  95746.0000  5.0000 


Iteration 
373.0000 
Iteration 
373.0000 
Iterat ion 
374.0000 
Iteration 
374.0000 
Iteration 
376.0000 
Iterat ion 
379.0000 
Iteration 
391.0000 
Iteration 
399.0000 
Iterat ion 
404.0000 
Iteration 
434.0000 
Iterat iot 
493.0000 


373.0000 

373.0000 

374.0000 

374.0000 

376.0000 

379.0000 

392.0000 

129 

390.0000 

256 

405.0000 

512 

437.0000 

1024 

499.0000 


64 


0.0000 

O.ODOO 

0.0000 

0.0000 

0.0000 

0.0000 

1.0000 

1.0000 

1.0000 

3.0000 

6.0000 


Teat  Manat  C000002  CUaa  Haaei  Tasking 

CPU  Tiaei  1035.2  aicrooeconda 

Mall  Tiaai  1035.2  aicroaeconda.  Iteration  Counti  1024 

Test  Description! 

Task  create  snd  terainste  ties  asesuraaent. 

with  one  task,  no  sntries  when  task  is  in  a  proceuhtre, 

taak  defined  and  used  in  procedure,  no  select  ststeaant,  no  loop 


Iteration 
979.0000 
Iteration 
979.0000 
Iterat ion 
979.0000 
Iterat  ion 
979.0000 
Iteration 
990.0000 
Iterat ion 
991.0000 
Iteration 
993.0000 
Iteration 
997.0000 
Iterat ion 
995.0000 
Iterat ion 
1009.0000 
Iteration 
1039.0000 
Iteration 
1096.0000 


1 

979.0000 

2 

979.0000 


• 

16 

32 

64 

129 


979.0000 

979.0000 

990.0000 

992.0000 

994.0000 

999.0000 


256 

996.0000 

512 

1012.0000 

1024 

1044.0000 

2049 

1109.0000 


0.0000 
O.ODOO 
0.0000 
0.0000 
0.0000 
1.0000 
I .0000 
I .0000 
1.0000 
3.0000 
6.0000 
12 .0000 


Test  Nsosi  N000004  Claas  Haaei  Chapter  13 

CPU  Tiaei  444.3  aicrooeconda 

Mall  Tiaei  444.3  aicroaeconda.  Iteration  Counti  2049 

Test  Description  I 

Tlaa  to  perfora  standard  boolean  operationa  on  arrays  of  booleana. 
for  this  test  the  arrays  are  NOT  PACEBD  with  the  pragaa  'PACX.' 
for  this  tMt  the  operations  are  perforaed  on  coigxMients  in  a  loop. 


Test  Haaei  T000004  Class  Haaai  Tasking 

CPU  Tiaei  556.6  aicroaeconda 

Mall  Tiaei  556.6  eicroaeconds.  Iteration  Coonti  1024 

Test  Deseriptioni 

Task  entry  call  and  return  tlae  aasaured 

One  tasks  active,  two  entries,  tasks  in  a  package 

using  aelect  stateaant 


Teet  Nseei  M)00090 
Clock  resolution  eaaaureaant  running 
Tent  Deseriptioni 

Oetenaine  clock  resolution  using  second  differences 
of  values  returned  by  the  function  CPU  TiaeC lock . 


Nu^wr  of  asi^le  vaioes  ia 
Clock  Reeolution 
Clock  Resolution  (average) 
Clock  Reeolution  (variance) 


1.000000000000000  seconds. 
1.000000000000000  seconds. 
0.000000000000000  seconds . 


Test  Naosi  A000091  Claas  Maaei  Cooposite 

1.2000  is  tiae  in  ailllaeconds  for  one  Ohrystone 
Test  Description! 

Relnhold  P.  Meicker’B  ONhYCTOm  co^ioaite  benchaark 


aei  00^1  CIS  Ite 


Iteration  1 

1799.0000  1799.0000 

Iteration  2 

1799.0000  1799.0000 

Iteration  4 

1799.0000  1799.0000 

Iteration  9 

1799.0000  1799.0000 

Iteration  16 

1799.0000  1799.0000 

Iteration  32 

1799.0000  1799.0000 

Iteration  6  4 

1900.0000  1900.0000 

Iteration  129 

1901.0000  1902.0000 

Iteration  256 

1903.0000  1904.0000 

Iteration  512 

1906.0000  1909.0000 

Iteration  1024 

1912.0000  1919.0000 

Iteration  2049 

1925.0000  1937.0000 

Iteration  4096 

1950.0000  1974.0000 

Iteration  9192 

1999.0000  1947.0000 


0.0000 
0.0000 
0.0000 
0.0000 
0.0000 
0.0000 
0.0000 
1.0000 
1 .0000 
3.0000 
6.0000 
12.0000 
24.0000 
49.0000 


Teet  Mat 


A000092 


Claas  MSI 


112 


Iteration  1*314 

144*. 0000  2043.0000  4S.0000 

Taat  Hasai  OOOOOOl  Claaa  Raaai  Orocadure 

CfU  Tiaai  4.  3  alcroasconda 

Mall  Tiaat  4.3  aicroaaconda.  Itaration  Countt  1*304 

Taat  OaacripCiont 

Procadura  oall  and  raturn  tiaa  (  aay  ba  saro  if  autoaatic  inlininq  ) 
(urocadura  la  local 
no  paraaatara 


Itaration  1 

2147.0000  2147.0000  0.0000 

Itaration  2 

2140.0000  2140.0000  0.0000 

Itaration  4 

2140.0000  2140.0000  0.0000 

Itaration  0 

2140.0000  2140.0000  0.0000 

Itaration  1* 

2140.0000  2144.0000  1.0000 

Itaration  32 

2144.0000  2144.0000  0.0000 

Itaration  *4 

2200.0000  2200.0000  0.0000 

Itaration  121 

2201.0000  2202.0000  l.OOOO 

Itaration  25* 

2203.0000  2^04.0000  1.0000 

Itaration  512 

2207.0000  2210.0000  3.0000 

Itaration  1024 

2214.0000  2221.0000  7.0000 

Itaration  2040 

2224.0000  2242.0000  13.0000 

Itaration  404* 

2254.0000  2215.0000  24.0000 

Itaration  1142 

2110.0000  2370.0000  52.0000 

Itaration  1*104 

2434.0000  2534.0000  103.0000 

Taat  HaMi  MOOOlO 

CPU  Tiaai  10. 1  aicroaaconda 

Mall  Tiaai  10. 1  aicroaaconda. 

Taat  Oaacriptioni 

Proeadura  call  and  raturn  tiaa  aaasur 
CoaiMra  to  4000005 
10  paraMtara,  in  tmcOO 


Itaration  1 

2*74.0000  2*14.0000  0.0000 

Itaration  2 

2*75.0000  2*75.0000  0.0000 

Itarat ion  4 

2*75.0000  2*75.0000  0.0000 

Itaration  • 

2*75.0000  2*75.0000  0.0000 

Itaration  1* 

2*74.000''  2*7*. 0000  0.0000 

Itarat  ion  12 

2*77.0000  2*77.0000  0.0000 

Itarat inn  *4 

2*74.0000  2*71.0000  0.0000 

Itaration  (24 

2*03.0000  2*04.0000  1.0000 

Itaration  25* 

2*40.0000  2*42.0000  2.0000 

Itaration  M2 

2705.0000  2700.0000  i.OOOO 

Itaration  1024 

2734.0000  2714.0009  5.0000 

Itaration  2040 

2741.0000  2002.0000  11.0000 

Taat  IkiMi  TOOOOOl  Claaa  Haani  Taakinq 

CPU  Tiaai  454.1  aicroaaconda 

Mall  Tiaai  454.1  aicroaaoonda.  Iteration  Count i  2040 

Taat  Oaaoriptioni 

Hlniaaa  randareoaai  antry  call  and  ratam  tiaa 
I  taak  I  ant  ry  >  taak  Inaldn  procadara 
no  aalact 


Itaration  1 

2400.0000  2400.0000  0.0000 

Itarat Ion  2 

2400.0000  2400.0000  0.0000 

Itarat  loi  4 

2404.0000  2404.0000  0.0000 

Itarat  ton  0 

2410.0000  2410.0000  0.0000 

Itarat ion  1* 

2411.0000  2411.0000  O.OOOC 

Itaration  32 

2413.0000  2413.0000  0.0000 

Itarat ion  *4 

2417.0000  2410.0000  1.0000 

Itaration  120 

2425.0000  2424.0000  1.0000 

Itaration  25* 

2442.0000  2441.0000  1.0000 

Itarat ion  512 

2474.0000  2477.0000  1.0000 

Itarat ion  1024 

3030.0000  3044.0000  4.0000 

Taat  Naaai  T000004  Claaa  Haaai  Tasking 

CPU  Tiaai  5*4.4  aicroaacoada 

Mall  Tiaari  54*. 4  alcroaaeowda.  Itaration  coanti 

Taat  Oaacriptioni 

Taak  antry  call  and  ratam  tiaa  taaaaarad 
On#  taaka  activa,  two  antrlaa,  taaka  in  a  packaqa 
ualn^  aalact  atatanant 


Claaa  Maani  proeadura 
Itarat  ion  Count  i  1*304 


1024 
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